从SAML迁移到OpenID Connect

Question

由于SAML和OpendID Connect（OIDC）是处理身份验证/SSO的根本不同的方法，它们是否可能并排存在于同一个应用程序中？

作为一个拥有许多使用SAML进行身份验证的供应商（外部）应用程序的组织，从SAML切换到OIDC是否合理，这样我们就可以转向更现代/更简单的单点登录解决方案？

像Okta这样的主要ID管理提供商有很多关于如何实现SAML或OIDC的文档，但我找不到任何人或任何文档提到从一个迁移到另一个涉及到的工作级别。有人做过吗？涉及到什么？

Answer 1

只要你有两个栈，是的，它们可以并排存在，你可以有两个登录按钮——每个协议一个，

当它们转到同一个IDP时，两者的凭据是相同的。

要从一个堆栈移动到另一个堆栈，基本上需要将一个堆栈撕下，然后用另一个堆栈替换。

OIDC使用JWT令牌。声明具有不同的名称，您可能无法扩充标准集。

SAML没有什么问题。我认为这本身没有好处。将旧的OIDC留给所有新的开发。

Answer 2

由于SAML和OpendID Connect（OIDC）是处理身份验证/SSO的根本不同的方法，它们是否可能并排存在于同一个应用程序中？

协议，它们是不同的。但它们的作用是相同的，即实现身份验证和授权。现在，当你们提到应用程序时，我们倾向于考虑最终用户应用程序。例如，webhtml" target="_blank">应用程序、独立桌面应用程序或移动应用程序。从这样的应用程序中，我认为不需要支持多个协议。在实现和可维护性方面，这样的应用程序很容易支持一个authN

但是如果您考虑服务器端，特别是暴露数据和服务的API，那么您将必须支持多个authN

也就是说，通常身份提供者支持多种协议。例如，Azure AD支持SAML2.0和OpenID Connect。因此，当您的应用程序涉及后端API/服务时，请求可能来自SAML或OpenID Connect。您必须通过过滤层进行理想的验证，以检测、验证和验证请求。

像Okta这样的主要ID管理提供商有很多关于如何实现SAML或OIDC的文档，但我找不到任何人或任何文档提到从一个迁移到另一个涉及到的工作级别。有人做过吗？涉及到什么？

在设计应用程序时，最好隔离AuthN

对于新的应用程序，最好使用OpenID Connect。但是，您可能会发现迁移所有应用程序很困难（取决于它们的复杂性）。因此，在后端支持这两者是理想的。此外，请尝试始终从身份提供程序存储和检索身份详细信息。这样，协议的更改很容易，因为它们（身份提供者）支持多种协议。