OAuth 2.0：在授权代码流程中，谁最终将访问令牌交给我的 Web 浏览器？

Posted 2023-03-10

【中文标题】OAuth 2.0：在授权代码流程中，谁最终将访问令牌交给我的 Web 浏览器？

【英文标题】：OAuth 2.0: In the authorization code flow, who eventually hands the access token to my web browser?

【发布时间】：2022-01-16 22:59:29

【问题描述】：

我正在学习 OAuth 2.0。

在 OAuth 2.0 中，术语“授权类型”是指应用程序获取访问令牌的方式。

在隐式流程中，授权服务器会将浏览器重定向回应用程序指定的redirect_uri，并在 URL 的片段部分添加令牌和状态。所以我认为最终用户的网络浏览器将获得 access_token 值。

但是在代码流中，Auth 服务器似乎会向我的 Web 浏览器提供一个临时代码，然后我的 Web 浏览器会向应用程序发送附有此代码的 http 请求。然后应用程序调用 Auth 服务器的 /oauth/token 端点以将该临时代码与访问令牌交换，因此它最终从 auth 服务器获取访问令牌。

那么故事就这样结束了吗？

应用程序是否更进一步将访问令牌提供给我的网络浏览器？

我一直认为，为了能够与应用程序交互（在我使用应用程序时向它发送越来越多的 HTTP 请求），每个 http 请求都会附加一个访问令牌，因此请求是有效命中应用程序的端点。

但在代码流中，我作为最终用户，在完成 OAuth 代码流并开始与应用程序交互后，似乎在我的浏览器中没有访问令牌？

应用程序如何知道我确实是那时的我？

【参考方案1】：

浏览器不需要访问令牌，因为它不能用它做任何事情。浏览器理解或处理访问令牌的方式与它们理解和处理 cookie 的方式不同。

在隐式流程中，令牌被发送到浏览器，但假设您在浏览器中运行自己的应用程序（通常是单页应用程序），它将读取令牌并将其附加到任何后续请求。或者，如果您使用 OpenID Connect 和 ID 令牌对用户进行身份验证，则使用该令牌的内容。

当浏览器将授权代码发送到您的应用程序并且您的应用程序将其交换为访问令牌时，您的应用程序应该为该浏览器中的用户建立会话。然后，当同一用户向您的应用发出请求时，您可以使用分配给该用户会话的访问令牌。

通常，您的应用会使用此访问令牌来调用其他一些 API，但如果您只需要该访问令牌来识别用户并让用户访问您的应用，那么您真正需要的很可能是普通的旧会话，不是 OAuth。

【讨论】：

谢谢你的回答。这让事情变得更加清晰。今天学习很好！