使用 SSO 而不是 OAUTH 的 Web API authentication/authorization - 它会起作用吗？
Web API authentication/authorization using SSO instead of OAUTH - will it work?
根据@user18044 下面的问题更新
如果用户通过 2 个不同的基于 SAML 的身份提供商在两个不同的 Web 应用程序中进行身份验证，并且其中一个应用程序需要从另一个应用程序公开的 Web API 请求数据，是否会是否可以根据用户在两个应用程序中的当前身份验证状态安全地调用 Web API 方法，而无需通过 API 级别的身份验证协议（例如 OAUTH）单独保护 API 方法？请注意，这两个应用程序均由我的公司拥有和运营，并且共享相同的二级域和用户群，即使身份服务器不同（一个是遗留的）。
一些进一步的信息：应用程序 A 是一个门户应用程序，它将使用应用程序 B 提供的数据托管小部件。应用程序 A 将仅通过应用程序 B 公开的 Web API 与应用程序 B 通信。目前应用程序 B 不公开 Web API（应用程序本身内部除外）。这是需要添加到应用程序 B 的新功能。应用程序 A 将使用 Okta 作为其 SSO。我们的首席架构师的建议是继续使用我们内部开发的基于 dk.nita.saml20 DLL 的自定义遗留 IDP 服务器。我相信它们都是基于 SAML 的，但我不认为它们可以在不进行一些改造的情况下共享相同的身份令牌。但这触及了我对身份验证主题的知识限制。 :) 我认为我们的架构师的计划是让用户使用两个不同的身份提供者分别进行身份验证，然后仅使用 CORS 保护网络 API，他的理由是因为用户已知并经过身份验证可以使用应用程序 B ，允许应用程序 A 调用应用程序 B 的 web api 方法不会有任何安全隐患，因为用户应该在应用程序 B 中进行身份验证。这对我来说似乎很古怪，因为我可以想象很多发生的浏览器重定向可能对用户不透明，但除此之外，我只是想找出安全漏洞可能存在的位置，因为我觉得会有一些。
我知道这种方法不会被认为是最佳实践，但是话虽如此，我真的很想知道为什么不这样做。有安全隐患吗？它甚至可以工作吗？如果是这样，在实施过程中是否有任何 "gotchas" 或需要考虑的事项？
重申一下，我们的首席架构师提出了这个解决方案，但它没有通过我的直觉检查，但我对这个话题的了解还不足以证明我的立场是正确的，或者让我感到足够自在地接受他的建议.希望有安全高手赐教。
如果不进一步了解您当前的应用程序和 APIs 是如何被准确保护的，就很难回答。 Web 应用程序及其 API 是否具有相同的依赖方标识符（即是否可以使用相同的令牌对两者进行身份验证）？
如果两个 Web 应用程序都使用 WS-Federation 协议对用户进行身份验证，那么 SAML 令牌很可能会存储在身份提供商将令牌发回应用程序时设置的 cookie 中。
您无权访问来自 JavaScript 的这些 cookie。如果属于应用程序 B 的 Web API 使用相同的基于 cookie 的身份验证机制，您可以使用它，前提是您允许 cross origin resource sharing.
如果您的网站 API 使用不记名令牌身份验证方案（如 OAuth）或在 STS 中具有不同的依赖方 ID，这显然行不通。
我认为你的直觉检查失败的原因是因为你基本上是以 cross-site request forgery attack 会做的方式访问网络 API。
我发现这种方法的一个问题是，如果用户未通过其他 Web 应用程序的身份验证，那么对您的 API 的调用也会失败。
就跨站点请求伪造攻击和应用程序之间的安全性而言，我同意 user18044。如果用户 X 可以访问应用程序 A，那么他们就可以访问应用程序 B，反之亦然吗？如果不是这种情况，那么每个应用程序都需要单独进行身份验证......并且它不会是 SSO。我发现这些链接可能对您的情况有所帮助。
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations
根据@user18044 下面的问题更新
如果用户通过 2 个不同的基于 SAML 的身份提供商在两个不同的 Web 应用程序中进行身份验证，并且其中一个应用程序需要从另一个应用程序公开的 Web API 请求数据，是否会是否可以根据用户在两个应用程序中的当前身份验证状态安全地调用 Web API 方法，而无需通过 API 级别的身份验证协议（例如 OAUTH）单独保护 API 方法？请注意，这两个应用程序均由我的公司拥有和运营，并且共享相同的二级域和用户群，即使身份服务器不同（一个是遗留的）。
一些进一步的信息：应用程序 A 是一个门户应用程序，它将使用应用程序 B 提供的数据托管小部件。应用程序 A 将仅通过应用程序 B 公开的 Web API 与应用程序 B 通信。目前应用程序 B 不公开 Web API（应用程序本身内部除外）。这是需要添加到应用程序 B 的新功能。应用程序 A 将使用 Okta 作为其 SSO。我们的首席架构师的建议是继续使用我们内部开发的基于 dk.nita.saml20 DLL 的自定义遗留 IDP 服务器。我相信它们都是基于 SAML 的，但我不认为它们可以在不进行一些改造的情况下共享相同的身份令牌。但这触及了我对身份验证主题的知识限制。 :) 我认为我们的架构师的计划是让用户使用两个不同的身份提供者分别进行身份验证，然后仅使用 CORS 保护网络 API，他的理由是因为用户已知并经过身份验证可以使用应用程序 B ，允许应用程序 A 调用应用程序 B 的 web api 方法不会有任何安全隐患，因为用户应该在应用程序 B 中进行身份验证。这对我来说似乎很古怪，因为我可以想象很多发生的浏览器重定向可能对用户不透明，但除此之外，我只是想找出安全漏洞可能存在的位置，因为我觉得会有一些。
我知道这种方法不会被认为是最佳实践，但是话虽如此，我真的很想知道为什么不这样做。有安全隐患吗？它甚至可以工作吗？如果是这样，在实施过程中是否有任何 "gotchas" 或需要考虑的事项？
重申一下，我们的首席架构师提出了这个解决方案，但它没有通过我的直觉检查，但我对这个话题的了解还不足以证明我的立场是正确的，或者让我感到足够自在地接受他的建议.希望有安全高手赐教。
如果不进一步了解您当前的应用程序和 APIs 是如何被准确保护的，就很难回答。 Web 应用程序及其 API 是否具有相同的依赖方标识符（即是否可以使用相同的令牌对两者进行身份验证）？
如果两个 Web 应用程序都使用 WS-Federation 协议对用户进行身份验证，那么 SAML 令牌很可能会存储在身份提供商将令牌发回应用程序时设置的 cookie 中。
您无权访问来自 JavaScript 的这些 cookie。如果属于应用程序 B 的 Web API 使用相同的基于 cookie 的身份验证机制，您可以使用它，前提是您允许 cross origin resource sharing.
如果您的网站 API 使用不记名令牌身份验证方案（如 OAuth）或在 STS 中具有不同的依赖方 ID，这显然行不通。
我认为你的直觉检查失败的原因是因为你基本上是以 cross-site request forgery attack 会做的方式访问网络 API。
我发现这种方法的一个问题是，如果用户未通过其他 Web 应用程序的身份验证，那么对您的 API 的调用也会失败。
就跨站点请求伪造攻击和应用程序之间的安全性而言，我同意 user18044。如果用户 X 可以访问应用程序 A，那么他们就可以访问应用程序 B，反之亦然吗？如果不是这种情况，那么每个应用程序都需要单独进行身份验证......并且它不会是 SSO。我发现这些链接可能对您的情况有所帮助。
https://developer.salesforce.com/page/Implementing_Single_Sign-On_Across_Multiple_Organizations