I don't know if I just have some kind of blind spot or what, but I've read the OAuth 2 spec many times over and perused the mailing list archives, and I have yet to find a good explanation of why the Implicit Grant flow for obtaining access tokens has been developed. Compared to the Authorization Code Grant, it seems to just give up on client authentication for no very compelling reason. How is this "optimized for clients implemented in a browser using a scripting language" (to quote the specification)?
这两个流程的起点是相同的(来源:https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-22):
客户端通过将资源所有者的用户代理定向到授权端点来启动流。
授权服务器对资源所有者进行身份验证(通过用户代理)，并确定资源所有者是否授予或拒绝客户端的访问请求。
假设资源所有者授予访问权限，授权服务器使用前面提供的重定向URI(在请求中或在客户端注册期间)将用户代理重定向回客户端。
重定向URI包括一个授权代码(授权代码流)
重定向URI在URI片段中包含访问令牌(隐式流)
这里是流分裂的地方。在这两种情况下，此时重定向URI指向客户端托管的某个端点:
In the Authorization code flow, when the user agent hits that endpoint with the Authorization code in the URI, code at that endpoint exchanges the authorization code along with its client credentials for an access token which it can then use as needed. It could, for example, write it into a web page that a script on the page could access.
The Implicit flow skips this client authentication step altogether and just loads up a web page with client script. There's a cute trick here with the URL fragment that keeps the access token from being passed around too much, but the end result is essentially the same: the client-hosted site serves up a page with some script in it that can grab the access token.
因此我的问题是:跳过客户端身份验证步骤可以获得什么?
虽然隐式授权的设计是为了支持不能保护客户端机密的应用程序，包括客户端JavaScript应用程序，但一些提供商正在实现一种替代方案，使用没有客户端机密的授权代码。OAuth 2.0 IETF RFC-6749于2012年发布，目前的建议是2017年的一些最新讨论。
关于IETF OAuth邮件列表的2017年讨论可从以下实现者获得:
红帽:https://www.ietf.org/.../oauth/current/msg16966.html
德国电信:https://www.ietf.org/.../oauth/current/msg16968.html
智能健康IT: https://www.ietf.org/.../oauth/current/msg16967.html
点击此处阅读更多信息:
https://aaronparecki.com/oauth-2-simplified/
https://aaronparecki.com/oauth-2-simplified/#single-page-apps
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: Redhat, Deutsche Telekom, Smart Health IT.
从隐式授权转移到没有客户端机密的认证代码也提到了这里的移动应用:
https://aaronparecki.com/oauth-2-simplified/#mobile-apps
它可以归结为:如果用户正在运行一个基于浏览器或“公共”(JavaScript)的web应用程序，没有服务器端组件，那么用户隐含地信任该应用程序(以及它运行的浏览器，可能与其他基于浏览器的应用程序……)
没有第三方远程服务器，只有资源服务器。授权代码没有任何好处，因为除了浏览器之外，没有其他代理代表用户。出于同样的原因，客户端凭证没有任何好处。(任何客户端都可以尝试使用此流。)
然而，这对安全的影响是重大的。从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.3:
当使用隐式授权类型时，访问令牌将在中传输
URI片段，这可能会将其暴露给未经授权的一方。
从https://www.rfc-editor.org/rfc/rfc6749 #节- 10.16:
资源所有者可以自愿将对资源的访问委托给
向攻击者的恶意客户端授予访问令牌。这可能
可能是因为网络钓鱼或其他借口…
