安全问题
以下是构建授权服务器时应考虑的一些已知问题。
网络钓鱼Attack
针对 OAuth 服务器的一种潜在Attack是网络钓鱼Attack。这是Attack者创建一个看起来与服务授权页面相同的网页的地方，该页面通常包含用户名和密码字段。然后，Accacker可以通过各种手段诱骗用户访问该页面。除非用户可以检查浏览器的地址栏，否则该页面可能看起来与真正的授权页面完全相同，并且用户可以输入他们的用户名和密码。
Attacker试图诱骗用户访问假冒服务器的一种方法是将此网络钓鱼页面嵌入到本机应用程序的嵌入式 Web 视图中。由于嵌入式 Web 视图不显示地址栏，因此用户无法通过视觉确认他们访问的是合法站点。不幸的是，这在移动应用程序中很常见，而且开发人员通常希望通过在整个登录过程中将用户留在应用程序中来提供更好的用户体验。一些 OAuth 提供商鼓励第三方应用程序打开 Web 浏览器或启动提供商的本机应用程序，而不是允许它们在 Web 视图中嵌入授权页面。
对策
确保通过 https 提供授权服务器以避免 DNS 欺骗。
授权服务器应该让开发人员了解网络钓鱼Attack的风险，并可以采取措施防止页面嵌入本机应用程序或 iframe 中。
应该对用户进行有关网络钓鱼Attack的危险的教育，并应向他们传授最佳实践，例如仅访问他们信任的应用程序，并定期查看他们已授权的应用程序列表以撤销对他们不再使用的应用程序的访问权限。
该服务可能希望在允许其他用户使用该应用程序之前验证第三方应用程序。Instagram 和 Dropbox 等服务目前就是这样做的，在最初创建应用程序时，该应用程序只能由开发人员或其他列入白名单的用户帐户使用。应用程序提交审批和审核后，即可供服务的整个用户群使用。这使服务有机会检查应用程序如何与服务交互。
点击劫持
在点击劫持Attack中，Attack者创建一个恶意网站，在Attacer网页上方的透明 iframe 中加载授权服务器 URL。Attacker的网页堆叠在 iframe 下面，并且有一些看起来无害的按钮或链接，非常小心地放置在授权服务器的确认按钮的正下方。当用户单击具有误导性的可见按钮时，他们实际上是在单击授权页面上的不可见按钮，从而授予对Attacker应用程序的访问权限。这允许Attacker在用户不知情的情况下诱骗用户授予访问权限。
对策
通过确保授权 URL 始终直接加载到本机浏览器中，而不是嵌入到 iframe 中，可以防止这种Attack。较新的浏览器可以让授权服务器设置 HTTP 标头，X-Frame-Options而较旧的浏览器可以使用常见的 Javascript “frame-busting”技术。
重定向 URL 操作
Attacker可以使用属于已知良好应用程序的客户端 ID 构造授权 URL，但将重定向 URL 设置为Attacker控制下的 URL。如果授权服务器不验证重定向 URL，并且Attacker使用“令牌”响应类型，则用户将返回到Attacker的应用程序，URL 中包含访问令牌。如果客户端是公共客户端，并且Attacker拦截了授权码，那么Attacker也可以用授权码交换访问令牌。
另一种类似的Attack是Attacker可以欺骗用户的 DNS，并且注册的重定向不是 https URL。这将允许Attacker伪装成有效的重定向 URL，并以此方式窃取访问令牌。
“开放重定向”Attack是指授权服务器不需要重定向 URL 的精确匹配，而是允许Attacker构建将重定向到Attacker网站的 URL。无论这最终是否被用于窃取授权码或访问令牌，这也是一种危险，因为它可用于发起其他不相关的Attack。有关开放重定向Attack的更多详细信息，请访问https://oauth.net/advisories/2014-1-covert-redirect/。
对策
授权服务器必须要求应用程序注册一个或多个重定向 URL，并且仅重定向到与先前注册的 URL 完全匹配的位置。
授权服务器还应该要求所有重定向 URL 都是 https。由于这有时会成为开发过程中的负担，因此在应用程序“开发中”时允许非 https 重定向 URL 并且只能由开发人员访问，然后要求将重定向 URL 更改为 https 也是可以接受的应用程序发布并可供其他用户使用之前的 URL。
