azure - OAuth 2.0 授权码授予无 secret

Question

所以我一直在考虑使用 Microsoft cordova-plugin-ms-adal plugin 为 Cordova 移动应用程序设置 OAuth 2.0 (使用 native 库)针对使用 Azure AD 的自定义 API。这一切都运行良好，但我对 secret 的使用(或更具体地说它的缺失)有点困惑。

在网络上的许多文章中，他们指出，当使用授权代码授予并请求 token 时，您需要包含该 secret 。当您可以安全地存储 secret 时，例如，这种授权类型非常适合使用在服务器上。

但是，该插件不需要在应用程序中指定 secret (这是正确的)，但它仍然使用授权代码授予来进行身份验证。我也可以手动调用

https://login.windows.net/common/oauth2/authorize?resource=http://***.onmicrosoft.com/***API&client_id=***&response_type=code&redirect_uri=http://***.onmicrosoft.com/***App

在我的浏览器中，登录，获取代码，然后 POST 到 https://login.windows.net/common/oauth2/token与

grant_type: authorization_code
client_id: ***
code: ***
redirect_uri: http://***.onmicrosoft.com/***App
resource: http://***.onmicrosoft.com/***API

它有效，所以我拿回了一个有效的 JWT，无需发送 secret 。

为什么!？这是不是不太安全？ (我还注意到 OAuth 2.0 spec section 4.1.3 没有说明授予类型授权代码需要该 secret !？)

使用授权类型的授权代码而不使用 secret /基本身份验证 header 会产生什么影响？

Answer 1

对所谓的 secret 客户端(具有客户端 secret 的客户端)使用授权代码授予确实比使用公共(public)客户端更安全。

这是因为授权代码本身的交换是作为前端 channel 中的 URL 参数进行的，即通过浏览器进行的，因此相对容易受到跨脚本、点击劫持、网络/DNS 操纵等攻击。意味着专门的攻击者在某些情况下有可能窃取用户的授权代码(粗心的用户、攻击者的网络控制、服务器实现中粗心的重定向 URI 匹配等)。

要将授权代码交换为访问 token ， secret 客户端必须在 HTTPs protected 调用中与授权代码一起提供客户端 secret ，而公共(public)客户端没有任何方法来确保它是确实是指定的客户。

这意味着攻击者相对容易模仿公共(public)客户端，因为这只需要非 secret 信息(他可以获取 client_id 和 >redirect_uri(来自他自己的浏览器)以及他可以通过上述攻击获取的授权code。

虽然获取 secret 客户端的授权代码的方式相同，但攻击者无法使用它并将其交换为访问 token ，因为为了做到这一点，他需要一个客户端 secret ，而该 secret 通常对于攻击者。该 secret 通常存储在服务器的后端存储中，并且仅通过安全的 HTTPs channel 进行通信，因此不会泄露。