为什么 OAuth 2.0 规范建议使用 HTTP GET 向客户端提供授权代码？

Question

在 OAuth 2.0 规范中，作者建议¹ 使用 HTTP 302 重定向到先前提供的

redirect_uri

- 很可能指向后端服务器（机密客户端）来实现

Authorization Response

。这将使用户（资源所有者）的浏览器（用户代理）对该 URI 执行 GET 请求。然后，客户端将使用此请求中包含的授权代码从授权服务器获取访问代码，并以某种适当的方式回答此请求。

但是这个操作 - 由 GET 请求触发 - 不是 idempotent 没有在客户端实施重要的额外措施，并且 当然 不是 safe。因此它与 HTTP-GET 的要求相矛盾。

这是合理的担忧吗？在实现我自己的 OAuth 2.0 客户端的重定向端点时，我应该如何考虑这一点？

---

¹：准确地说，用于重定向的确切方法是一个实现细节，但所有示例都使用

302

（请参阅规范的 1.7 部分）。

Answer 1

下面是一个授权响应的例子，作为一个HTTP GET，它是幂等的。例如，您可以收到响应，然后在使用授权代码之前多次重新加载浏览器 URL。

HTTP GET https://www.example.com?code=xxx&state=yyy

非幂等的是 OAuth 工作流中的下一个请求，POST 授权代码授予消息，交换令牌的代码。

POST http://login.example.com/oauth/token
Content-Type: application/x-www-form-urlencoded

client_id=myclient
&client_secret=mysecrrt
&code=xxx
&grant_type=authorization_code
&redirect_uri=http://www.example.com/callback

响应模式

如今将 OIDC 和 OAuth 一起使用很常见。 OpenID Connect 规范定义了一个

response_mode

参数，其默认值为

query

。如果您愿意，这使您能够以不同的方式接收授权响应：

• response_mode=form_post
• response_mode=jwt