客户端应该使用 GET 还是 POST 获取 OAuth 2 访问令牌?

发布于 2024-12-18 03:06:57 字数 588 浏览 4 评论 0原文

OAuth 2.0 草案 v2-22 第 3.2 节说:

客户端在创建访问令牌时必须使用 HTTP“POST”方法 请求。

但是,如果您查看 FacebookFoursquare OAuth2 实现,它们要求客户端发出简单的 GET 请求来请求访问令牌。他们要求客户端将 client_id 和 client_secret 放在 URL 中。

我正在构建一个 OAuth 2 服务器,在看到 Facebook 和 Foursquare 的实现之后,我强烈考虑也打破协议以允许客户端通过 GET 请求访问令牌。我的网站的通信使用 SSL,类似于 Facebook 和 Foursquare。

所以我的问题是:是否有任何充分的理由为什么我不应该允许客户端通过 HTTPS 上的 GET 方法请求访问令牌?

The OAuth 2.0 draft v2-22 Section 3.2 says:

The client MUST use the HTTP "POST" method when making access token
requests.

However, if you look at the Facebook and Foursquare OAuth2 implementations, they ask the clients to make a simple GET request for requesting an access token. They ask the clients to place the client_id and client_secret in the URL.

I am building an OAuth 2 server and after seeing Facebook's and Foursquare's implementations, I am strongly considering also breaking the protocol to allow clients to request the access token via GET. My site's communication is using SSL, similar to Facebook and Foursquare.

So my question is this: Are there any good reasons why I shouldn't allow clients to request access tokens via the GET method over HTTPS?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

夜无邪 2024-12-25 03:06:57

最常见的论点是,您不应将敏感信息放入查询字符串(GET 参数)中,因为 Web 服务器通常会记录 HTTP 请求 URL。 POST 数据可以任意长,因此通常不记录。因此,当您处理诸如 client_secret 或代码之类的内容(尽管它是一次性使用)时,将其传递到 POST 有效负载中是有意义的。

恕我直言,如果您使用不需要 client_secret 的 OAuth 2.0 流程(或者按照建议将其放入 HTTP 授权标头中) - 我没有发现允许 GET 存在问题。

The most common argument is that you should not put sensitive information in a query string (GET parameter) as Web servers typically log the HTTP request URL. POST data can be arbitrarily long, so is not usually logged. Therefore when you're dealing with something like client_secret or code (although it's one time use), it makes sense to have that passed in the POST payload.

IMHO, if you're using an OAuth 2.0 flow that doesn't require client_secret's (or you put that in the HTTP Authorization header, as recommended) - I don't see an issue with allowing GET.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文