隐式授权工作流程与仅用于身份验证的授权代码授予的缺点？答案

【问题标题】：Disadvantages of the Implicit Authorization Workflow vs Authorization Code Grant for Authentication Only?隐式授权工作流程与仅用于身份验证的授权代码授予的缺点？
【发布时间】：2017-10-16 04:34:14
【问题描述】：

对于经典网络应用程序，我无法弄清楚将授权码授予与隐式流用于仅用于身份验证目的的优势？

比如说，有一个网络应用程序通过第 3 方 Iaas 提供商进行身份验证。 Web 应用程序只需要知道用户（由某个 ID 标识）是否经过身份验证。该网络应用程序不会访问任何第 3 方服务，因此不需要任何访问令牌来进行授权。

在此示例中，我看不到从 IaaS 直接将 user_id（JWT 令牌）获取到 Web 浏览器比通过 Web 后端获取相同的 user_id 更不安全？在这两种情况下都将建立一个会话。如果我在这种情况下使用隐式授权，我会失去什么？

【问题讨论】：

标签： oauth-2.0 jwt openid

【解决方案1】：

隐式流是一个遗留流，当时浏览器只能调用同一个源服务器。使用隐式流时的问题之一是它在重定向中返回访问令牌。重定向可以是包含访问令牌的浏览器历史记录的一部分。此外，如果多个设备历史记录与您的浏览器同步，则会增加安全风险。

虽然在授权代码流（使用 PKCE） 中没有访问令牌作为 URL 的一部分，这使其更安全。

您可以参考Is the OAuth 2.0 Implicit Flow Dead?了解更多详情

【讨论】：

【解决方案2】：

取决于您的网络应用程序在哪里运行。如果它完全在浏览器上运行（例如，它是一个 javascript 应用程序或 SPA），那么我将使用 implicit 流，因为 Authorization code 授权已针对机密客户端进行了优化。

如果您的 Web 应用在服务器上运行，那么使用 Authorization code 授权会更安全，因为令牌会从 IaaS 提供商（Auth 服务器）直接发送到 Web 应用服务器(client) 而不是通过用户的 (resource owner) 浏览器。

【讨论】：

authorization code 授权不需要安全客户端。该授权类型可以（并且正在）被智能手机上的本机应用程序使用，而这些应用程序可能根本不受保护。正确的问题是：is the client running **completely** inside of a web browser。如果答案是肯定的，则使用隐式授权类型，否则使用 authorization code（对于本机应用程序使用 PKCE）。请参阅alexbilbie.com/guide-to-oauth-2-grants 或（优秀书籍）manning.com/books/oauth-2-in-action 以获得更好的解释
浏览器中运行着一个客户端，它向我的服务器上运行的网络服务器发出请求。每个文件都建议使用授权码。在这种情况下，我仍然不明白它比隐式授权更安全。例如，在授权授权的情况下，一旦客户端通过身份验证，服务器将与客户端建立会话，该会话仍可能包含相同的 user_id。所以看起来它只是添加到授权服务器的双重往返？
@MikhailY 它更安全，因为 Id / Access 令牌不需要转到最终用户的浏览器。
@MikhailY 服务器没有与客户端建立任何会话。授权码用于获取访问令牌（用于执行 API 调用）。没有发布user_id。身份验证是通过 OpenID Connect 扩展完成的。用户的 ID 在id_token 中，而不是在访问令牌中。
@FlorentMorselli 正确，这就是问题所在。获取id_token，为什么隐式流程比授权码授权流程差？