桥接 SAML 和 OAuth 2.0 框架是一个很好理解的问题。以下 IETF 规范堆栈提供了标准解决方案：

• 如果您查看核心OAuth 2.0 规范(RFC 6749) 及其令牌端点定义——这基本上是一个 OAuth 服务器端点，它返回一个访问令牌以换取“授权”——一个被认为适合的开放式概念授予客户端应用程序访问令牌的问题。在典型的 OAuth 场景中，这是一个授权代码，表示用户之前已经过身份验证并获得了他们的同意。但赠款也可能是别的东西。

• 还有一个名为draft-ietf-oauth-assertions-16 的IETF 规范，它建立在核心 RFC 6749 标准之上，该标准说授权也可以是一个断言（某事的签名证明），并为此定义了必要的令牌请求参数.

• 最后，还有draft-ietf-oauth-saml2-bearer-20，它指定此断言如何成为 SAML 2.0 Bearer Assertion。

这种将 SAML 断言转换为 OAuth 2.0 访问令牌的标准机制基本上就是桥接这两个框架所需的全部内容。

为确保授权系统正确反映用户的删除，有两种方法可以组合使用：

• 使 OAuth 2.0 访问令牌短暂存在。这将强制客户端在令牌过期时重复授权过程，如果用户不再存在，身份验证将失败并且不会发出授权（SAML 断言）。
• 提供用于撤销已发布的 OAuth 2.0 访问令牌的 API，有关详细信息，请参阅RFC 7009。

我所知道的这种组合的唯一实现是 Salesforce。您要做的是一个复杂的设置 - 两种协议都不简单，并且它们的交互存在问题，例如您提到的那个。

看看这个文档（SF 实现从外部看起来是什么样的） - https://wiki.developerforce.com/page/Single_Sign-On_for_Desktop_and_Mobile_Applications_using_SAML_and_OAuth

并检查此草稿（我个人没有仔细研究过它，但它专门针对您的情况https://datatracker.ietf.org/doc/html/draft-ietf-oauth-saml2-bearer-16

OAuth 是一个授权框架。来自RFC6749

OAuth 2.0 授权框架使第三方应用程序能够获得对 HTTP 服务的有限访问权限

SAML 是一个身份验证框架。SAML 断言包含身份验证信息。通常 SAML 用于 SSO，但 SAML 标准还包含一个 Authorization decision assertion. 可以用来携带一些授权信息。

您可以从此处的 SAML 文档中获得更多信息。

该问题没有提供有关系统实施的详细信息，但我建议使用 SAML 2.0 的授权功能，而不是尝试合并两个完全不同的标准，用于不同的目的