OAuth2（授权代码授予类型）的重定向 URI 中是否应该存在动态查询参数

诸如此类的来源Okta 赞助网站 https://www.oauth.com/oauth2-servers/redirect-uris/redirect-uri-registration/（参见“按请求定制”部分）提到授权请求的redirect_uri参数永远不应该有动态查询部分（例如：用于会话匹配用途）。

Quote:

服务器应拒绝任何带有重定向 URL 的授权请求 与注册的 URL 不完全匹配。

我们的 OAuth AZ 提供商是 BIG-IP F5。我们正在设置，他们似乎也符合上述观点。

我们的客户是在其他地方构建的Web应用程序，他们似乎不遵循上述规则。 以下是授权端点的完整表示（已编辑）：

他们使用的redirect_uri格式类似于（为了简单起见，我在这里不进行urlencode）：redirect_uri=https://ourClientAppHostname/ClientRessource/Ressource?SessionId=SOMELONGSESSIONID https://ourClientAppHostname/ClientRessource/Ressource?SessionId=SOMELONGSESSIONID，每次调用的 SOMELONGSESSIONID 值都不同。

We dug DEEP进入 RFC6749 (OAuth2)，并在第 3.1.2.2 节中找到：

授权服务器应该要求客户端提供
完整的重定向 URI（客户端可以使用“state”请求
参数来实现每个请求的定制）。如果需要
无法注册完整的重定向 URI，
授权服务器应该要求注册 URI
方案、权限和路径（允许客户端动态改变
仅请求时重定向 URI 的查询部分
授权）。

我理解并且想在这里验证的是，第一个来源 Okta 和 F5 仅接受上述规则的第一部分，并且要求重定向 uri 完全注册，没有任何动态部分。

我是否正确地确认他们（Okta 和 F5）不遵守摘录的第二部分，理由是他们应该“允许客户端动态变化 仅请求时重定向 URI 的查询部分 授权" ?

或者，RFC6749 是否有任何形式的官方更正/演变，可以保证两家公司的设计立场？

TL;DR:

不可以，出于安全原因，重定向 URI 必须是静态的。如果客户需要保留state在授权请求及其异步响应之间，使用 OAuth 2.0state范围。

长版 :

RFC6749（最初的 OAuth 2.0 规范）已于 2012 年发布，自那时起 OAuth 安全环境已经发生了很大变化。

RFC6819，2013 年的 OAuth 2.0 安全审查 https://www.rfc-editor.org/rfc/rfc6819#section-5.2.3.3已经提到，拒绝动态制作的重定向 uri 是防止 XSS 和客户端模拟攻击的好方法。

OpenID 连接 https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest从 2014 年开始，OAuth 2.0 的常用扩展（具有身份验证功能）已经考虑了该建议，并要求所有重定向 uri 进行精确的字符串匹配。

OAuth 2.0 最佳安全实践的当前建议草案 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-12#section-3.1通过强制redirect_uris预注册并要求AS在验证请求中传递的redirect_uri时使用简单字符串比较来确认这一点。因此不得使用动态redirect_uri。

通过使用动态制作的方法，您的客户端使用redirect_uri作为授权请求和响应之间的“状态守护者”，肯定会做出错误的举动SessionID属性内的redirect_uri。 OAuth2.0为此目的有一个专用的授权请求参数，即“state https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1”。客户端应该使用它。AS 在发出响应时会将该状态附加到redirect_uri 的参数中，以便客户端能够在响应中找到该状态。

正确的授权请求是：

https://youras/authorize?client_id=your_client_id&response_type=code&state=SOMELONGSTATE&redirect_uri=https%3A%2F%2Fsomehost%2Fauthcallback

响应将如下所示： https://somehost/authcallback?state=SOMELONGSTATE&code=anazcode

这样，redirect_uri 是静态的，因此简单的字符串比较足以在 AS 端验证该 uri。任何比简单字符串比较更复杂的算法都会存在安全缺陷。