OAuth 2.0：在授权码流程中，谁最终将访问令牌交给我的Web浏览器？ [英] OAuth 2.0: In the authorization code flow, who eventually hands the access token to my web browser?

问题描述

我正在学习OAuth 2.0。

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

在隐式流中，授权服务器将浏览器重定向回应用程序指定的redirect_uri，将令牌和状态添加到URL的片段部分。因此，我认为最终用户的Web浏览器将获得ACCESS_TOKE值。

然而，在代码流中，身份验证服务器似乎会给我的Web浏览器提供一个临时代码，然后我的Web浏览器向应用程序发送http请求，并附上此代码。然后，应用程序调用身份验证服务器的/oauth/token端点来与访问令牌交换该临时代码，因此它最终从身份验证服务器获得访问令牌。

这就是故事的结尾吗？

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

我一直认为，为了能够与应用程序交互(在我使用应用程序时向其发送越来越多的HTTP请求)，每个http请求都将附加一个访问令牌，以便请求有效地到达应用程序的终结点。

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

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

推荐答案

浏览器不需要访问令牌，因为它无法对其执行任何操作。浏览器理解或处理访问令牌的方式与其理解和处理Cookie的方式不同。

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

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

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

这篇关于OAuth 2.0：在授权码流程中，谁最终将访问令牌交给我的Web浏览器？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！