像这个 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
他们使用格式类似于(为了简单起见，我在这里不 urlencode)的redirect_uri：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，以保证两家公司的设计立场？
TL;DR：
否，出于安全原因，重定向 uri 必须是静态的。如果客户端需要在授权请求与其异步响应之间保持state，请使用 OAuth 2.0state参数。
长版：
RFC6749(最初的OAuth 2.0规范)已于2012年发布，自那时以来，OAuth安全环境发生了很大变化。
RFC6819,2013 年的 OAuth 2.0 安全审查已经提到，拒绝动态制作的重定向 URI 是防止 XSS 和客户端模拟攻击的好方法。
OpenID Connect，从2014年开始，OAuth 2.0的常用扩展具有身份验证功能，已经考虑了该建议，并要求所有重定向URI进行精确的字符串匹配。
当前关于 OAuth 2.0 最佳安全实践的建议草案确认了这一点，通过强制执行redirect_uris预注册并强制要求在验证请求中传递的redirect_uri时由 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。任何比简单字符串比较更复杂的算法都会受到安全漏洞的影响。
这里似乎有两件事混淆了： 您引用的 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 匹配锁定为"精确"，在这种情况下，您必须配置所有可能的 SessionId。