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

Question

诸如Okta赞助站点之类的消息源（请参阅“按请求自定义”部分）提到，自动请求的redirect_uri参数不应包含动态查询部分（例如：用于会话匹配）。

引用：

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

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

我们的客户是在其他地方构建的Web应用程序，它们似乎不遵循上述规则。这是授权端点的完整表示（已编辑）：https ://ourownF5host.ca/f5-oauth2/v1/authorize ? client_id = theIDofOurClient & redirect_uri =https% 3A%2F%2FourClientAppHostname%2FClientRessource%2FRessource%3FSessionId%3D76eab448-52d1 -4adb-8eba-e9ec1b9432a3＆state = 2HY-MLB0ST34wQUPCyHM-A＆scope = RessourceData＆response_type = code

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

我们将DEEP挖入RFC6749（OAuth2），并在第3.1.2.2节中找到了这一点：

授权服务器应该要求客户端提供
完整的重定向URI（客户端可以使用“ state”请求
参数来实现每个请求的自定义）。如果
不可能要求注册完整的重定向URI，则
授权服务器应要求注册URI
方案，权限和路径（允许客户端
在请求
授权时仅动态更改重定向URI的查询组件）。

我了解并希望在此进行验证的是，第一个来源Okta和F5仅接受上述规则的第一部分，并且要求重定向uri必须完全注册而没有任何动态部分。

我是否可以肯定他们（Okta和F5）不遵守摘录的第二部分，并指出他们应“ 允许客户端在请求授权时仅动态更改重定向URI的查询组件 ”？

或者，是否有任何形式的RFC6749官方更正/发展可以保证两家公司的设计地位？

Answer 1

TL; DR：

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

长版：

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

RFC6819（2013年的OAuth 2.0安全性评论）已经提到，拒绝动态制作的重定向uri是防止XSS和客户端模拟攻击的好方法。

自2014年以来，OpenID Connect（具有身份验证功能的OAuth 2.0的常用扩展）已经考虑了该建议，并要求所有重定向uri都必须进行精确的字符串匹配。

OAuth 2.0最佳安全性实践的当前建议草案通过执行以下步骤来确认这一点：在验证请求中传递的redirect_uri时，强制执行redirect_uris预注册并由AS强制使用简单字符串比较。因此，不得使用动态redirect_uri。

通过在redirect_uri SessionID内部使用动态制作的属性，将redirect_uri用作授权请求和响应之间的“状态守卫者”，您的客户端肯定会做出错误的举动。OAuth2.0为此具有专用的授权请求参数，即“ 状态 ”。客户应使用它。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。任何比简单字符串比较复杂的算法都将存在安全漏洞。