从SAML迁移到OpenID Connect

Question

作为处理身份验证/单点登录的基本不同方法，SAML和OpendID Connect（OIDC）是否可以在同一应用程序中并存？

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

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

- Justin

Answer 1

由于SAML和OpenID 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是个好主意。但你可能会发现难以迁移所有应用程序（取决于它们的复杂性）。因此，在后端支持两者是理想的。此外，尝试始终从身份提供者中存储和检索身份详细信息。这样，更改协议就很容易，因为它们（身份提供者）支持多个协议。

- Kavindu Dodanduwa

---

你能帮我解决这个 Stack Overflow 上的问题吗？https://dev59.com/vajka4cB1Zd3GeqPGva_ - Alex Man

Answer 2

只要您有两个堆栈，它们可以并排存在，并且您可以拥有例如两个登录按钮-每种协议一个。

由于它们都使用相同的IDP，因此两者的凭据是相同的。

从一个协议转换到另一个协议基本上涉及将一个堆栈拆除并用另一个堆栈替换。

OIDC使用JWT令牌。声明具有不同的名称，您可能无法增加标准设置。

SAML没有任何问题。我认为本质上没有好处。保留旧有的内容-对所有新开发使用OIDC。

- rbrayb