OAuth 2.1 是否需要将每个前端路径配置为有效的redirect_uri？

Question

可能是一个非常普遍的问题：OAuth 2.1 是否需要将每个前端路径配置为有效

redirect_uri

？

参见：https://oauth.net/2.1/

Redirect URIs must be compared using exact string matching

我们想知道这将如何处理用户访问应用程序时

access_token/refresh_token

过期的流程。

一个常见的流程（以及我们使用的流程）是这样的：

1. 用户登录并通过网络应用程序进行导航。 ->

   https://webpage.io/account/me

2. 用户丢失会话（删除cookie、会话过期、没有refresh_token等）。
3. 用户被重定向到登录页面 但是

   redirect_uri

   设置为用户离开的位置。 ->

   https://provider.io?redirect_uri=https://webpage.io/account/me

使用 OAuth 2.1，我们是否必须启用应用程序拥有的每条路由作为有效的

redirect_uri

到目前为止？如果

redirect_uri

包含通配符

*

，那么它就可以工作，但是这如何与精确的字符串匹配一起工作？

Answer 1

不，本身不存在“通配符”。

将您希望用户最终返回的 URL 粘贴到您的会话中 - 然后在用户再次到达您的 static

redirect_uri

后（并且您验证了成功/获得您的访问令牌），

或

将 URL 放入

state

参数中 - 这是

redirect_uri

中唯一允许偏离您的 注册 重定向 URI 的部分。

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10#section-2.3.1：

如果需要，客户端可以使用状态请求参数来实现每个请求的自定义，而不是改变每个请求的重定向 URI。

state

参数通常用于防止 CSRF 攻击 - 通过传递一个随机值，该值也会存储到用户会话中，并在用户返回重定向 URI 时比较这两个值。如果您已经以这种方式使用它，您可以为

state

参数提供一个编码为 JSON 的数据结构，以便您可以将随机会话状态和所需的目标 URL 都保留在其中。 （您必须在 CSRF 检查发生时相应地对其进行解码。）