我们有一个内部基于SAML2令牌的IDP。它与网站等配合得很好，但我们正在构建一个新的移动应用程序，由于移动应用程序与SAML的配合不好，我们正试图在mobile应用程序和IDP之间设置一个代理服务提供商/依赖方。代理SP的唯一功能是接受SAML令牌并建立会话，然后使用OpenID Connect与移动应用程序通话。过去，我们已经成功地与另一个客户一起使用了AWS cognito，但我们正在从AWS转向Azure，并想知道Azure B2C是否是我们需要使用的。有人对此或类似的事情有任何经验吗。具体来说，我们需要研究Azure AD还是Azure AD B2c？它需要能够添加一个外部身份提供程序(基于SAML(，接收SAML令牌并重定向到带有身份验证代码的返回url。从那里开始，它与OIDC的流动非常直接。
TIA莫汉
我建议逐步转向具有以下行为的体系结构：
- API在每个请求上都会接收JWT访问令牌，并可以使用它来保护数据请求
- Web和移动客户端通过OpenID Connect和授权服务器(AS(对用户进行身份验证，然后接收访问令牌，以便他们可以调用API
- AS以允许您控制访问令牌中发布的作用域和声明的方式发布令牌
- AS可以与各种身份提供商集成，包括SAML
所有这些都允许您使用最佳功能对应用程序进行编码，并在所有UI和API技术堆栈中提供一流的支持。Azure AD是AS的一个例子，我将从一个尖峰开始，看看它的SAML集成是否适用于您。
AS是体系结构的重要组成部分，而不仅仅是一个代理。从web后端架构(仅支持浏览器客户端(转移到web、移动和API架构时，通常会引入一种架构。
令牌的内容也很重要，因为JWT将通过AS而不是SAML IDP的主题声明来识别用户。这可能不适用于您现有的后端。
所以所有这些都需要一个建筑设计。例如，这篇详细的入门文章描述了常见的需求，重点是控制您的数据。
一个重要的考虑因素是保持应用程序代码基于OAuth相关标准。然后，你应该能够针对任何AS.运行你的应用程序