5

诸如此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 值都不同。

我们深入研究了RFC6749 (OAuth2)，并在第 3.1.2.2 节中找到了这一点：

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

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

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

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

4

2 回答 2

11

TL;博士：

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

长版：

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

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

从 2014 年开始， OpenID Connect是具有身份验证功能的 OAuth 2.0 的常用扩展，已经考虑了该建议，并要求对所有重定向 uri 进行精确的字符串匹配。

OAuth 2.0 最佳安全实践的当前建议草案确认，通过强制执行 redirect_uris 预注册并强制 AS 在验证请求中传递的 redirect_uri 时使用简单字符串比较。因此，不得使用动态 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。任何比简单字符串比较更复杂的算法都会存在安全漏洞。

于 2019-04-08T16:16:10.423 回答
2

这里似乎有两件事混合在一起：您引用的 URL：

 https://somehost/authcallback?state=SOMELONGSTATE&scope=someobjecttype&response_type=code

建议您将客户端的重定向 URI（也称为回调 URL，如 URL 中的路径名所建议）与授权服务器的授权端点混合在一起。

只有授权端点会采用建议的参数，并且可能包含例如动态state值。客户端的重定向 URI 将不包含例如响应类型。

可以将redirect_uri参数添加到授权请求中，然后必须按照您描述的方式进行匹配。确认匹配后，授权服务器将重定向回重定向 URI，添加code和state参数。

更新（问题改变后）：

OAuth 2.0 RFC6749 允许动态 (SessionId) 参数，尽管它不是最佳实践。但是，如果您的客户端是 OpenID Connect 客户端，则不允许这样做，因为 OpenID Connect 规范（OAuth 2.0 的“配置文件”）将重定向 URI 匹配为“精确”，在这种情况下，您必须配置所有可能的会话 ID。

于 2019-04-08T17:03:09.690 回答