OAuth2：查询字符串与片段

Posted 2023-04-15

【中文标题】OAuth2：查询字符串与片段

【英文标题】：OAuth2: query string vs. fragment

【发布时间】：2013-01-20 08:51:07

【问题描述】：

刚刚注意到，在 OAuth2 中，当请求的授权类型为：“code”时，回调将其包含在查询字符串参数中（在“？”之后）。但是，当授权是“令牌”时，它作为片段传递（在“#”之后）。

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

做出这种决定的理由是什么？

谢谢， 彼得

【参考方案1】：

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

在授权码授予的情况下，您通常有一个直接与提供者对话的网络应用程序，将数据发送到主机正是您所需要的：

Web 应用程序将您的浏览器重定向到您登录的提供商。 现在，提供程序会告诉您的浏览器 Web 应用程序的回调 URL 并附加 授权码。此代码必须发送到 Web 应用程序，因此它作为查询参数包含在对回调 URL 的请求中。 现在，Web 应用程序本身在后台与提供者对话，并使用 授权码 验证他确实被允许向提供者查询 访问令牌。

如果是隐式授权，您通常会在浏览器中直接运行一些 javascript 应用程序。无需向主机传递任何授权码，在大多数情况下也无需向主机发送访问令牌，因为浏览器中的JS可以直接与提供者交谈。这样你可以例如在服务器上创建一个网站，该网站使用从另一个提供商查询的信息，并征得用户同意，其中服务器永远访问用户的任何机密数据。 （如果是受信任的网站，则不会将 访问令牌 发送到服务器。）

【讨论】：

这是一个很好的解释。我目前遇到的一个问题是，并非所有用户代理（Safari 就是其中之一）都可靠地将片段作为重定向的一部分传递。奇怪的是，该片段存在于 http 上，但在 https 上却丢失了。因此，我已经走上了使用查询字符串的路线，由于您提到的原因，这当然是不太理想的。

@d0nut 我能够通过使用处理 oauth 回调响应的页面预加载弹出窗口来支持第三方的 Safari 和片段...我不知道它为什么有效，但它确实有效。结帐adodson.com/hello.js