OAuth2:查询字符串与片段[英] OAuth2: query string vs. fragment

本文是小编为大家收集整理的关于OAuth2:查询字符串与片段的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

刚刚注意到,当请求的赠款类型为:"代码"中的OAuth2中,该回调包含在查询字符串参数中('?'之后).但是,当赠款为"令牌"时,它将作为片段传递('#'之后).

这看起来是规格的一部分( https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.2 )

这种决定背后的理由是什么?

谢谢, piotr

推荐答案

当您的浏览器被网站重定向到带有查询参数的URL时,查询字符串也是浏览器现在发送给主机的请求的一部分.片段仅由您的Web浏览器在本地评估,而不包含在主机的请求中.

如果授权代码授予,您通常拥有一个直接与提供商交谈的Web应用程序,将数据发送到主机是您所需要的:

  • Web应用程序将您的浏览器重定向到您登录的提供商.
  • 提供商现在告诉您的浏览器Web应用程序的回调URL,并附加授权代码.此代码必须发送到Web应用程序,因此将其作为查询参数包括在回调URL的请求中.
  • 现在,Web应用程序本身在后台与提供商进行对话,并使用授权代码验证他确实可以向提供商查询访问令牌 <<<<<<<./li>

在隐式授予的情况下,您通常会在浏览器中直接运行一些JavaScript应用程序.无需将任何授权代码传递给主机,在大多数情况下,也无需将访问令牌发送给主机,因为浏览器中的JS可以直接可以与提供商交谈.这样,您可以例如在服务器上使用从其他提供商那里查询的信息创建网站,该信息在用户的同意下,服务器从不 Never 可以访问用户的任何机密数据. (如果是一个受信任的网站,则不会将访问令牌发送到服务器.)

本文地址:https://www.itbaoku.cn/post/2091033.html

问题描述

Just noticed that in OAuth2 when the requested grant type is: "code" the callback contains it in the query string parameters (after '?'). However, when the grant is "token" it is passed as a fragment (after '#').

This looks to be part of a spec (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.2)

What could be a rationale behind such decision?

Thanks, Piotr

推荐答案

When your browser gets redirected by a website to a URL with a query parameter, the query string is also part of the request that your browser now sends to the host. Fragments are only evaluated locally by your web browser and not included into the request to the host.

In case of the Authorization Code Grant, where you typically have a web application, that directly talks to a provider, sending the data to the host is exactly what you need:

  • The web application redirects your browser to the provider where you log in.
  • The provider now tells your browser a callback URL of the web application and appends an authorization code. This code has to be sent to the web application, so it is included as a query parameter into the request to the callback URL.
  • The web application now itself talks to the provider in the background and verifies with the authorization code that he is indeed allowed to query the provider for an access token.

In case of the Implicit Grant, you typically have some Javascript application directly running in your browser. There's no need to pass any authorization code to the host and in most cases there's also no need to send the access token to the host, as the JS in the browser can directly talk to the provider. This way you could e.g. create a website on a server that uses information queried from another provider with consent from the user where the server never gets access to any confidential data of the user. (In case of a trusted website, that doesn't send the access token to the server.)