由于SAML和OpendID Connect（OIDC）是处理身份验证/ SSO的根本不同的方法，它们是否可以在同一个应用程序中并存？
作为一个拥有许多使用SAML进行身份验证的供应商（外部）应用程序的组织，从SAML切换到OIDC是否合理，以便我们可以转向更现代/更简单的单点登录解决方案？
像Okta这样的ID管理的主要提供商有很多关于如何实施SAML或OIDC的文档，但是我找不到任何人或任何文档提到从一个迁移到另一个涉及到什么级别的工作。有人做过吗？涉及什么？
答案 0 :(得分：4)
只要您有两个堆叠，是的，它们可以并排生活，您可以拥有，例如两个登录按钮 - 每个协议一个，
当他们转到相同的IDP时，两者的凭据都是相同的。
从一个移动到另一个基本上涉及撕掉一个堆叠并用另一个堆叠替换它。
OIDC使用JWT令牌。声明具有不同的名称，您可能无法扩充标准集。
SAML没有任何问题。我认为本身没有任何好处。留下旧的 - 使用OIDC进行所有新开发。
答案 1 :(得分：4)
由于SAML和OpendID Connect（OIDC）是根本不同的方法 处理身份验证/ SSO，它们是否可能存在 并排在同一个应用程序中？
协议方面，它们是不同的。但它们用于同一目的，实现身份验证和授权。现在，当您说应用程序时，我们倾向于考虑最终用户应用程序。例如，Web应用程序，独立桌面应用程序或移动应用程序。从这样的应用程序，我认为不需要支持多种协议。实施和可维护性明智，这种应用程序很容易支持一个authN＆amp; authZ协议。
但如果您考虑服务器端，特别是您的API公开数据和服务，那么您将不得不支持多个authN＆amp; authZ协议。例如，您的服务可能由使用SAML的应用程序和某些使用OpenID Connect的应用程序使用。因此，这些应用程序将使用SAML断言或OpenID Connect令牌，您必须验证这些令牌。在这种情况下，它不是迁移，而是添加对多个authN＆amp;的支持。 authZ方法。
说，通常身份提供商确实支持多种协议。例如，Azure AD支持SAML 2.0和OpenID Connect。因此，当您的应用程序进入后端API /服务时，SAML或OpenID Connect可能会提出请求。您必须通过过滤层进行理想的验证，以检测，验证和验证请求。
像Okta这样的ID管理的主要提供商有很多关于如何实现SAML或OIDC的文档，但是我找不到任何人或任何文档提到从一个迁移到另一个涉及到什么级别的工作。有人做过吗？涉及什么？
在设计应用程序时，最好隔离authN＆amp; authZ与核心逻辑相关的东西。这样，您就可以轻松地更改方法/协议。在一天结束时，您希望识别使用应用程序并获得他/她定义的权限的最终用户。因此，恢复识别协议的改变并不困难。但请记住，将会有一些工作，例如OpenID Connect令牌验证，令牌到期处理等等。使用库让生活更轻松
为新应用程序迁移到OpenID Connect是个好主意。但是您可能会发现很难迁移所有应用程序（取决于它们的复杂性）。因此，在后端支持两者都是理想的选择。此外，尝试始终存储和检索身份提供者的身份详细信息。这样，协议的更改很容易，因为它们（身份提供者）支持多种协议。