When a user clicks “Sign in”, they can log in to multiple applications without having to sign in again. The experience appears to be straightforward. However, an identity protocol is carrying authentication information behind it between systems. For teams evaluating openid authentication, the options are likely to be OpenID Connect (OIDC) or SAML. Both of them can support single sign-on (SSO), but they were created for different technology environments.
SAML 2.0 is an XML based protocol for communicating attributes and authentication between an identity provider (IdP) and service provider (SP). It became widely associated with enterprise browser-based SSO. OpenID Connect does things differently. It's an identity layer on top of OAuth 2.0. It can be used by an application (the Relying Party) to confirm the identity of an end user based on authentication performed by an OpenID Provider. An ID Token is a type of token that is typically used in OIDC. The difference in architecture becomes significant when applications go beyond the traditional enterprise software designed for the browser.
*Foundation: OpenID Connect is built on OAuth 2.0, while SAML 2.0 is built on the SAML framework. * Common format: OpenID Connect typically uses JSON/JWT, whereas SAML 2.0 uses XML. * Key identity artifact: OpenID Connect issues an ID Token, while SAML 2.0 issues a SAML assertion. * Typical fit: OpenID Connect suits web, mobile, APIs, and modern apps. SAML 2.0 is typically used for browser-based enterprise SSO. * Identity system: In OpenID Connect, the system that authenticates the user is called the OpenID Provider. In SAML 2.0, it is called the Identity Provider. * Application role: In OpenID Connect, the application relying on that authentication is the Relying Party or Client. In SAML 2.0, it is the Service Provider.
Neither protocol makes an application secure automatically. Correct implementation, token or assertion validation, key management, transport security, and configuration remain important.
Instead of asking which protocol is universally “better,” start with what must authenticate. Consider OIDC when the environment includes: * Native or mobile applications * JavaScript or modern web applications * API-centered architectures * OAuth 2.0 infrastructure * Applications that need standardized identity claims Discovery is also part of the OpenID Connect specification. It enables a client to learn about an OpenID Provider, such as the endpoints it supports and where they are located. So a suitable openid connect provider can thus be seamlessly integrated into modern identity architectures. When an organization has already developed enterprise applications that are able to accept SAML 2.0, then SAML is relevant. Not all integration issues need to be addressed by the migration of a working SAML integration, but rather if there is a need to migrate it.
This is where a difference can be explained more easily. SAML is based on an assertion from an identity provider. There are three types of statements in a SAML assertion: authentication statements, attribute statements, and authorization decision statements. The service provider uses the appropriate assertion to create the user's session or determine the user's access to the service based on its implementation. With OIDC, authentication results are represented through an ID Token. OIDC also defines claims about the authenticated user, and depending on the flow and requested scopes, applications may interact with the UserInfo Endpoint. Importantly, OAuth 2.0 alone is not an authentication protocol. OIDC adds the standardized identity layer needed for authentication.
Before standardizing on either protocol, ask: * Which protocols do existing applications actually support? * Are mobile, SPA, or API-driven applications part of the environment? * Is OAuth 2.0 already being used? * Are legacy enterprise applications dependent on SAML? * Does the identity platform need to support both during modernization? * How will tokens, assertions, signing keys, sessions, and logout be validated and managed? These questions can also be used to show that an enterprise doesn't require an all-or-nothing choice.
OIDC is well suited for many modern application architectures, whereas SAML is still used in many enterprise SSO environments. Both may be required for large organizations, especially to modernize legacy applications. Interoperability is the accepted better design principle. Match each application to the protocol that it supports, apply rigorous validation and identity controls, and use your identity architecture for consistent SSO for modern and legacy applications.