oauth-2.0 – 使用没有客户端密钥的授权代码替换OAuth2隐式授权

正在使用OAuth 2.0 Auth Code without Client Secret来代替少数公司的客户端 JavaScript应用程序的隐式授权.使用没有客户端秘密的Auth Code与隐式授权的一般优势/权衡是什么？是否有更多的公司和/或标准组织采用这种方式？

Red Hat,Deutsche Telekom和其他人已经按照这篇文章和下面的IETF OAuth邮件列表发布了这种方式.

> https://aaronparecki.com/oauth-2-simplified/

Implicit was previously recommended for clients without a secret,but has been superseded by using the Authorization Code grant with no secret.

…

Previously,it was recommended that browser-based apps use the “Implicit” flow,which returns an access token immediately and does not have a token exchange step. In the time since the spec was originally written,the industry best practice has changed to recommend that the authorization code flow be used without the client secret. This provides more opportunities to create a secure flow,such as using the state parameter. References: 07001,07002,07003.

以下是上面引用的消息.

Red Hat

For our IDP [1],our javascript library uses the auth code flow,but requires a public client,redirect_uri validation,and also does CORS checks and processing. We did not like Implicit Flow because

1) access tokens would be in the browser history

2) short lived access tokens (seconds or minutes) would require a browser redirect

Deutsche Telekom

Same for Deutsche Telekom. Our javascript clients also use code flow with CORS processing and of course redirect_uri validation.

SMART Health IT

We’ve taken a similar approach for SMART Health IT [1],using the code flow for public clients to support in-browser apps,and <1h token lifetime. (We also allow these public clients to request a limited-duration refresh token by asking for an “online_access” scope; these refresh tokens stop working when the user’s session with the AS ends — useful in systems where that session concept is meaningful.)