在 OAuth 重定向 URL 中有访问令牌是否很糟糕

Posted 2023-03-10

【中文标题】在 OAuth 重定向 URL 中有访问令牌是否很糟糕

【英文标题】：Is it bad to have access token in OAuth redirect URL在 OAuth 重定向 URL 中有访问令牌是不是很糟糕

【发布时间】：2021-01-28 13:52:37

【问题描述】：

我正在构建一个 oauth 登录流程，但我不确定我是否做错了，因为我需要通过重定向 URL 发回不记名令牌，例如 /oauth2/redirect?token=[TOKEN]。但是不建议通过 URL 传递令牌吗？正如thread 中指出的那样：

不要在页面 URL 中传递不记名令牌：不应该在页面 URL 中传递不记名令牌（例如，作为查询字符串参数）。相反，不记名令牌应该在 HTTP 消息头或对其采取保密措施的消息体。浏览器、Web 服务器和其他软件可能无法充分保护浏览器历史记录、Web 服务器日志和其他数据结构中的 URL。 如果不记名令牌在页面 URL 中传递，攻击者可能能够从历史数据、日志或其他不安全的位置窃取它们。

我一定错过了整个流程中的某些内容，并希望了解更多有关此问题的信息。任何意见表示赞赏！

更新

可能不正确，但这是我经过一番挖掘后的理解。传递token的三种方式：

网址（不推荐） 身份验证标头 请求正文

但在 oauth 重定向用例下，选项 2 和 3 不可行。所以选项 1 是唯一可用的选项。如果确实需要，可以对令牌进行加密以确保安全。

【问题讨论】：

在这里检查一下，它可能会有所帮助***.com/questions/29926041/…

@HaifengZhang 这似乎与我的问题完全相同。但是对于 oauth 用例是否有更好的方法来避免在 URL 中传递令牌，其中 auth head 或 post 请求都不是一个选项。

【参考方案1】：

基本的身份验证标头，提供一点额外的安全性，因为它需要通过 TLS：

在如图所示的“基本”身份验证的情况下，交换必须通过 HTTPS (TLS) 连接进行以确保安全。

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

此外，标头不会记录在浏览器历史记录等简单的地方。

根据规范，

它不应该被使用 除非不可能在 “授权”请求标头字段或 HTTP 请求实体主体。

https://www.rfc-editor.org/rfc/rfc6750#section-2.3

【参考方案2】：

我认为这仅意味着，当服务器需要令牌时，您不应使用 GET 请求，而应使用 POST 或任何合适的。在 GET 请求中，参数包含在 URL 中，这些参数最终会出现在日志或其他历史记录中，其他请求类型将发送与请求 URL 分开的参数。

附：顺便说一句，如果您自己没有实现 OAuth 服务器，则不必发送包含令牌的重定向 url。

【讨论】：

但是即使不是在 GET 请求中使用而是在重定向 URL 中使用，难道不是这样吗？ 如果不记名令牌在页面 URL 中传递，攻击者可能能够从历史数据、日志或其他不安全的位置窃取它们。 感谢您的输入。对于我的用例，我同时使用 OAuth 服务器以及与其他 3rd 方 OAuth 的集成，这就是我使用重定向 URL 的原因。如果没有其他人的意见，我会将其标记为已接受的答案。

@ChengXu - 这只会发生在令牌流中，当服务器发回重定向响应时，在这种情况下，承载令牌包含在重定向 URL 中，但（希望）受 SSL 保护.但是，如果您实现代码流，则重定向的 url 将仅包含一个代码，稍后可以将其交换为不记名令牌，此交换将通过 POSTrequest 完成。

@ChengXu - 也许一个误解是，重定向响应是由客户端执行的，但事实并非如此。重定向 url 是服务器的响应，但客户端实际上不会进行重定向，因此它不会最终出现在浏览器历史记录中。