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