当“隐式”流工作得如此好时，为什么在OAuth2中有一个“授权码”流？
使用“隐式”流，在资源所有者（即用户）给予访问权限后，客户端（可能是浏览器）将获得访问令牌。
然而，在“授权代码”流程中，客户端（通常是web服务器）只有在资源所有者（即用户）给予访问权限后才获得授权代码。使用该授权代码，客户机然后对API进行另一次调用，将client_id和client_secret与授权代码一起传递，以获得访问令牌。这里都描述得很好。
问题是：当“隐式”流接缝很好时，为什么还要费心用“授权码”流呢？为什么不对WebServer也使用“隐式”呢？
对于提供者和客户机来说，这都是更多的工作。
共有1个答案
TL；DR：这都是因为安全原因。
OAuth2.0希望满足以下两个标准：
- 您希望允许开发人员使用非HTTPS重定向URI，因为并非所有开发人员都有启用SSL的服务器，而且如果他们这样做了，也不总是正确配置（非自我签名、受信任的SSL证书、同步的服务器时钟……)。
- 您不希望黑客能够通过拦截请求窃取访问/刷新令牌。
- 它们不是HTTP请求的一部分，因此服务器无法读取它们，因此中间服务器/路由器也无法截获它们（这一点很重要）。
- 它们只存在于浏览器-客户端-因此读取哈希片段的唯一方法是使用在页面上运行的JavaScript。
这使得可以将访问令牌直接传递给客户机，而不会有被中间服务器截获的风险。这需要注意的是，只有客户端才可能使用访问令牌，并且需要运行客户端的javascript才能使用访问令牌。
隐式流还存在需要进一步逻辑来解决/避免的安全问题，例如：
-
null
您还可以辩称隐式流的安全性较低，存在潜在的攻击载体，如在重定向时欺骗域-例如通过劫持客户端网站的IP地址。这就是隐式流只授予访问令牌（应该有有限的时间使用）而从不刷新令牌（时间无限）的原因之一。为了解决这个问题，我建议您尽可能将网页托管在启用HTTPS的服务器上。
-
通过“隐式”流，在资源所有者（即用户）给予访问权之后，客户端（可能是浏览器）将获得一个访问令牌。 然而，对于“授权代码”流，客户端（通常是web服务器）仅在资源所有者（即用户）给予访问权之后才获得授权代码。使用该授权代码，客户机然后对API进行另一次调用，传递client_id和client_secret以及授权代码，以获得访问令牌。这里都有很好的描述。 这两个流具有完全相同的结果：访问令牌。不过
-
OAuth2.0有多个工作流。关于这两个问题，我有几个问题。 null 这两种方法在安全性方面有什么不同？哪一个更安全，为什么？ 当服务器可以直接发出访问令牌时，我看不出为什么在一个工作流中添加额外的步骤（令牌的交换授权代码）。 不同的网站说，授权码流是在客户端应用程序可以保持凭据安全的情况下使用的。为什么？
-
我对以下涉及oauth2的流程有一些问题： webapp1.xyz.com是具有授权代码授予类型的注册客户端，以下是当前流程： 用户登录并使用授权码重定向到webapp1.xyz.com webapp1.xyz.com交换访问令牌的授权代码并将其存储到会话 webapp1.xyz.com服务器端需要通过传递访问令牌调用webapp2.xyz.com api webapp1.xyz.com具有SPA
-
null 现在，我仍然困惑的是，登录验证应该从哪里来（登录用户名-密码）？是否在转到OAuth流之前进行单独的验证，一旦用户有效，它就应该回到流中？
-
双腿OAuth2用于基于浏览器的应用程序，在这种应用程序中，任何客户端凭据都不能对公众隐藏。“Web服务器应用程序”使用三条腿的OAuth2，其中服务器之间有第三个呼叫。这里描述得很好。 问题是：既然两条腿看起来很好，为什么还要用三条腿呢？ 这对提供者和客户来说都是更多的工作。为什么其中一个大咖不出手，去掉3条腿？
-
我想更好地理解隐式授权流和授权代码授权流之间的区别，因为我不确定我目前的理解是否正确。 隐式授权流主要由前端应用程序用于验证用户身份吗？ 隐式授权流是否只需要一个client_id、用户名和密码来进行身份验证，换句话说，永远不会发送client_secret？ 授权码只是一个短期令牌吗？ 将授权码交换为访问令牌后，客户端可以访问用户帐户多长时间？具体地说，如果客户端是一个长时间运行的脚本，那么用户