SAML vs OIDC
SAML and OIDC are the two most popular authentication protocols used in the SSO industry. This article will compare SAML and OIDC in terms of their architecture, and use cases.
What is SAML?
SAML (Security Assertion Markup Language) is an XML-based open standard for exchanging authentication and authorization data between different parties, in particular, between an identity provider (IdP) and a service provider (SP). It enables web-based SSO (Single Sign-On) allowing users to authenticate once to access multiple applications. SAML is a mature protocol that has been around for a long time and is widely adopted by enterprises. Some most popular SaaS platforms like Salesforce, Workday, and Microsoft Azure AD all support SAML SSO.
SAML components
- Identity provider (IdP): The entity that authenticates users and provides identity information to service providers.
- Service provider (SP): The entity that provides services to users and relies on the identity provider to authenticate users.
- SAML assertions: XML-based documents that carry the user's authentication and authorization details. Including, authentication statements, attribute statements, and authorization decision statements.
- SAML protocol: Defines the message format and rules for exchanging SAML assertions between the IdP and SP.
- SAML bindings: Defines how SAML messages are transported over different communication protocols like HTTP POST, HTTP Redirect, etc.
- SAML metadata: XML-based documents that contain the configuration information of the IdP and SP. It includes the public key, endpoints, and supported bindings that are used to establish trust between the IdP and SP.
- Signal sign-on endpoint: The endpoint where the SP redirects the user to authenticate with the IdP.
- Assertion consumer service (ACS) URL: The endpoint where the IdP sends the SAML assertion after successful authentication.
How SAML works?
- SP initiated SSO flow:
- IdP initiated SSO flow:
Advantages of SAML
- Mature and widely adopted: SAML is a mature protocol that has been around for a long time and is widely adopted by enterprises.
- Standardized: SAML is an open standard maintained by OASIS, ensuring interoperability between different vendors.
- SSO: SAML enables web-based SSO allowing users to authenticate once to access multiple applications.
- Centralized user management: SAML allows organizations to manage user identities centrally and enforce security policies consistently.
Challenges of SAML
- Complexity: SAML is a complex protocol that requires a deep understanding of XML and security concepts.
- Performance: SAML messages are XML-based and can be large. XML delivery and parsing can be slower compared to token formats like JSON Web Tokn (JWT).
- Outdated standard: SAML is an older standard compared to OIDC and considered less secure.
- Vender lock-in: SAML is a vendor-specific protocol, and switching between vendors can be challenging.
What is OIDC?
OIDC (OpenID Connect) is an identity layer built on top of the OAuth 2.0 protocol. Similar to SAML, OIDC is also used for exchanging authentication and authorization data between IdP and SP.
Compare to SAML, OIDC is a more modern and lightweight protocol that is gaining popularity for modern web and mobile applications. OIDC uses JWT for transmitting identity information, which is more compact and easier to work with compared to XML-based SAML assertions. It is especially popular for consumer-facing applications and API security.
OIDC components
- Identity provider (IdP): The entity that authenticates users and provides identity information to service providers.
- Relying party (RP):The entity that provides services to users and relies on the identity provider to authenticate users. E.g. web applications, mobile apps, or APIs.
- OIDC tokens: Tokens that carry the user's identity information.
- ID token: JWT format token that contains the user's identity information.
- Access token: JWT or opaque format token that grants access to protected resources.
- Refresh token: Token used to obtain a new access token without requiring the user to re-authenticate. It gives a offline long-lived authorization to the RP.
- OIDC endpoints: Endpoints used for authentication and token exchange. Some most important endpoints are:
- Discovery endpoint: Where the RP can retrieve the public OIDC configuration information from the IdP.
- Authorization endpoint: Where the RP send the authentication request.
- Token endpoint: Where the RP requests the authorization server for tokens.
- Userinfo endpoint: Where the RP can retrieve the user's profile information.
- Scopes: OIDC defines a set of standard scopes that define the access rights granted to the RP. Such as
openid
,profile
,email
,address
, etc.
How OIDC works?
OIDC provides multiple flows that are explicitly designed for different use cases. Here are two most common OIDC flows:
- Authorization code flow:
Authorization code flow is the most common flow used in OIDC for consumer-facing applications.
- Client credentials flow:
Client credentials flow can be used for non-user-based(machine-to-machine) authentication.
Advantages of OIDC
- Modern and lightweight: OIDC is a contemporary protocol that employs JSON-based JWT tokens, which are more compact and easier to handle compared to XML-based SAML assertions.
- Consumer-facing applications: OIDC is particularly popular for consumer-facing applications and API security.
- Interoperability: Built on top of OAuth 2.0, OIDC is compatible with diverse platforms, devices, and platforms.
- Security: OIDC offers a more secure method for user authentication and API protection. It incorporates various modern security features such as token introspection, token revocation, Proof Key for Code Exchange (PKCE), and supports different authentication flows adapted to various security needs.
- Ease of use: OIDC is simpler to implement and work with compared to SAML. It is more developer-friendly and has comprehensive libraries and SDKs for multiple programming languages and platforms.
Challenges of OIDC
- Token management: OIDC relies on tokens for authentication and authorization. It requires proper token management practices to ensure security.
- Complexity: Though OIDC is simple for basic setups, due to its flexibility nature, it can add complexity when implementing advanced customizations. E.g. custom claims, and Role-based access control (RBAC), etc.
- Adoption: OIDC is still relatively new compared to SAML, especially in the enterprise space. Some legacy systems may still rely on SAML for SSO purposes.
Comparison SAML vs OIDC
Aspect | SAML | OIDC |
---|---|---|
Token format | XML-based SAML assertions | JSON-based JWT tokens |
Primary use case | Enterprise SSO, B2B integrations | Consumer-facing apps, API security |
Ease of use | Complex, requires deep understanding of XML | Simple, JSON-based, easy to implement |
Adoption | Widely adopted by enterprises | Increasing popular for modern apps |
Security | Mature but considered less secure | Modern, and more secure |
Flexibility | Limited, designed for SSO use cases | Flexible, supports various use cases |
Future of SAML and OIDC
Both SAML and OIDC are widely used for authentication and authorization purpose.
SAML remains a cornerstone for enterprise SSO and B2B integrations. Its robust support for federated identity management and proven track record ensure its continued relevance, particularly for legacy systems and large-scale organizations.
OIDC, on the other hand, continues to evolve, driven by the demand for secure and scalable authentication in modern applications. Its lightweight nature and alignment with APIs and microservices make it a cornerstone for cloud-native and distributed architectures. With the rise of passwordless authentication, biometrics, and multi-factor authentication (MFA), OIDC is expected to integrate seamlessly with emerging technologies, ensuring its relevance in the years to come.