我知道SAML是如何工作的，我知道OAuth和OPENIDConnect是如何工作的。我知道 SAML 用于身份验证，OAuth 用于授权。但在某些文章中提到，当 2007 年 iPhone 进入时，在这种情况下 SAML 缺乏身份验证(对于移动应用程序)，我无法理解除了委托授权之外，为什么我们需要 OAuth 来解决移动身份验证问题(现在由 OPENIDConnect 完成)或者 SAML 如何无法处理该问题。有人可以帮助解决这种困惑吗？谢谢
几天前，我做了这个练习来识别SAML和OAUTH的应用程序。我将把我的发现粘贴在这里。
关于 - SAML
• 身份验证 • 授权(基于声明规则和断言属性)•
主要针对基于浏览器的登录流程设计•
最适合依赖集中式用户存储库的企业应用程序
• 内部部署和云应用程序联合很容易(例如，将用户存储库与云副本同步)，在这种情况下可以轻松传递用户属性
• 属性可以包含连接到另一个第三方应用程序的信息(凭据)(不推荐)
• 支持加密断言以提高安全性
• 单个 Req-Res 包含断言，避免对 IdP
进行任何其他调用• 集中管理用户和授权数据
• 联合元数据涉及复杂的结构、属性定义、公共证书、签名算法等•
定期证书滚动更新、CRL 管理、索赔规则管理
关于我们 - OAuth
•授权 • 需要单独的身份验证提供程序(通常与授权服务器结合使用)•
最适合多域、多用户存储库方案
• 可用于控制对单个资源(如帐户详细信息、文件或服务)的访问。可以授予临时/永久访问权限。
• 简单易懂，易于集成。减少客户必须执行的大量额外工作• 资源
所有者控制对资源的访问，可以有选择地授予对其他应用程序的各种功能的访问权限•
身份验证与业务逻辑分离•
针对不同用例的不同授权类型支持
• 获取令牌后，SP 必须进行额外的 API 调用以获取必要的信息/资源
• 标准化较弱 – 每个 IdP 都可以自定义实现，这需要 SP 端
的自定义• 仅依靠 HTTPS 进行加密，无需为正在传输
的数据定义额外的加密 回答您的问题 -您会发现很难应用 SAML
的地方
•应用程序间通信
• 不涉及
用户交互的后端作业、调度程序、业务逻辑• 与不受组织
管理或控制的外部 IDP 通信
SAML 不是为允许应用程序进行身份验证而设计的。它依赖于用于签名/验证、加密/解密的预共享密钥机制，该机制最好在服务器上处理，并以其他方式(如 OAuth 或 OIDC)将属性馈送到下游应用。您能想象仅仅因为 IdP 想要轮换其证书就需要更新几百万次应用安装吗？或者，更糟糕的是，IdP 的私钥被泄露了？SAML 中的密钥管理是一个足够困难的过程，如果您失败了，您面临的攻击就会有一个名称 - 黄金 SAML 攻击。
另一方面，OAuth 和 OIDC 的设计方式是，用于签名和加密的私钥应定期轮换。用于解密和验证的公钥由授权服务器 (AS) 或 OIDC 提供程序 (OP) 在可访问的端点上共享，授权服务器或 OIDC 提供程序 (OP) 由 AS/OP 在所需的元数据端点中公开宣布。这使得使用 AS/OP 的下游应用程序可以在轮换时获取所需的密钥。通常，应用程序将缓存密钥并使用它们，直到失败，此时它会检索新集。
OAuth和OpenID Connect是基于JSON的，可以在任何技术中很好地工作，包括Web和移动设备。
SAML 是基于 XML 的旧(后端)标准。它仍然广泛用于标识提供者，用于登录用户。
如今，人们根据OAuth和OpenID Connect编写应用程序(UI和API)，并且从不直接使用SAML。这导致移动应用程序、单页应用程序和 API 中的代码更简单。
这意味着应用程序与授权服务器 (AS) 交互。AS 可以与标识提供者通信(以支持多种用户登录方式)。如果需要，这可以包括与 SAML 提供程序的集成。
另请参阅我最近关于从应用程序功能的角度思考OAuth的回答。