SAML vs. OIDC: What's the Difference?

Identity management and secure access control are critical for any digital platform today. Cyberattacks and data breaches are becoming more common, so businesses need strong security methods that make sure users are who they say they are before they can access private resources.

Two widely used standards for handling authentication and authorisation are the Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). While both protocols enable secure single sign-on (SSO), they work quite differently under the hood.

By the end, you'll have clarity on the difference between OIDC and SAML across areas like protocol design, use cases, security considerations, and more.

What is SAML?

SAML (Security Assertion Markup Language) is an open standard authentication protocol that enables secure user access across multiple applications and domains based on single sign-on (SSO).

First released in 2002 by OASIS, SAML serves as the underlying technology behind most enterprise SSO systems today. It eliminates the need for users to authenticate separately to every application.

Instead, users authenticate just once with an identity provider that can then provide verified identity assertions to service providers.

Key SAML Capabilities:

• Enables SSO across participating web apps and portals
• Federated identity management between organisations
• XML-based protocol for exchanging authentication data
• Used widely across enterprises to unify access control

Its enterprise-centric design makes SAML a common choice for securing access to internal corporate applications and systems.

How Does SAML Work?

SAML serves as the underlying protocol for enabling SSO capabilities for web apps and services. It has been around since 2002, with the current SAML 2.0 version ratified in 2005.

At its core, SAML transmits user authentication and authorisation data between identity providers (IdPs) and service providers (SPs) via XML documents known as SAML assertions. An IdP first authenticates the user through a login portal and generates a SAML assertion encoding the user's verified identity attributes.

After receiving this SAML answer, the SP verifies the identity and grants access to the requested resources in accordance with their allocated permissions; this creates a circle of trust between the IdP and SPs, streamlining SSO across participating applications.

Common Components of SAML Transactions:

• SAML Request: Initiated by the SP to request user authentication from the IdP
• SAML Response: Generated by IdP after successful user login and conveyed to the SP
• SAML Assertion: Core XML document within the SAML Response that asserts authenticated user identity
• Signatures and Certificates: Cryptographically secures and validates SAML messages between parties

SAML Use Cases

Here are some common scenarios where SAML excels in enabling seamless SSO capabilities across organisational systems and boundaries:

• Enterprise SSO: SAML 2.0 provides the foundation for cross-platform single sign-on across an organisation's portfolio of cloud services, web applications, portals, and more. This enhances security while delivering simplified workforce access.
• Federated Identity: SAML enables federated identity management between partner organisations and third-party vendors collaborating on projects. This simplifies access control across company boundaries without separate logins.
• Cross-Domain SSO: SAML assertions facilitate single secure login sessions that seamlessly span across multiple sub-domains and paths within an organisation's web properties.
• Multi-Factor Access: SAML integrates directly with additional multi-factor and adaptive authentication services for increased account security beyond passwords.
• Healthcare SSO: Healthcare providers take advantage of SAML to streamline clinical access to patient health records across federated hospital systems.

When to choose SAML

SAML remains an appropriate choice where governance, compliance, and segmented access policy management are critical.

• Applications dealing with sensitive internal company data like HR records and financial reports
• Highly regulated sectors like healthcare and finance with audit requirements
• Enterprise integration scenarios connecting multiple internal legacy systems
• Customised multi-factor authentication policies mandated across specific apps or user groups

SAML is also preferred where existing IT infrastructure requires deep Windows Active Directory integration or vendors standardise primarily on SAML for standard packages.

What is OpenID Connect?

Released in 2014, OpenID Connect (OIDC) is a modernised authentication protocol layered on top of OAuth 2.0 – the popular standard for access delegation and authorisation.

It essentially overlays an identity verification layer on top of OAuth's authorisation flow. This allows applications to outsource user authentication to trusted identity providers based on tokenised access grants in OAuth.

Key OIDC Capabilities:

• Streamlined login for web/mobile apps using JSON tokens
• Federation via social login providers like Google and Facebook
• Builds on existing OAuth credentials and infrastructure
• Simpler security model relying on HTTPS transport encryption

OpenID Connect caters exceptionally well to consumer-facing applications like social, web, and mobile apps across personal devices. Its lightweight nature improves developer experience and end-user convenience.

How OpenID Connect Works

Instead of XML SAML assertions, OIDC uses compact JSON Web Tokens (JWTs) to transmit verified user identity claims between parties. JWTs are also digitally signed and optionally encrypted for security.

Some Key Differences in the OIDC Flow:

• Leverages OAuth for user authorisation with tokens
• No SAML requests/responses, just front channel redirects
• Identity tokens are delegated to OAuth providers like Google and FB.

OIDC Use Cases

Here are some examples of where OpenID Connect delivers the most value as an authentication protocol:

• Modern SSO: OIDC enables streamlined login experiences across modern desktop and mobile applications, over the web or locally installed.
• Mobile/Native Apps: Secure login system across iOS, Android, and other mobile/native app ecosystems while avoiding app-specific password lock-in.
• Federated Social Login: Frictionless integration with existing social media identities on platforms like Facebook, Google, Twitter, Github and more.
• Microservices and APIs: Fine-grained access control for microservices architectures where hundreds of mini-applications and APIs need authentication.
• CIAM Consumer Identity: Secure customer identity and access management for internet-facing properties used by external consumer identities.
• IoT Device Identities: Lightweight identity layer for authenticating non-traditional device identities in smart homes, wearables, and IoT ecosystems.

When to Choose OIDC

OIDC is best suited for customer-facing modern applications built using contemporary web stacks and coding languages, where convenience and trendy developer experiences outweigh strict access policy controls. Specific use cases include:

• B2C web/mobile applications with user signups
• Relying extensively on social login providers like Google and Facebook for convenience
• Primarily using microservices, REST APIs for business logic components
• Deployed entirely on cloud platforms like AWS that integrate more easily with OIDC

Additional drivers for OIDC include prioritisation of standards alignment, platform independence across user devices, and simplified integration overhead for developers.

Comparing Protocol Design

Now that we've covered the basics, let's compare some core protocol design elements between SAML and OIDC:

1. Message Encoding

SAML relies on verbose XML-based documents for conveying authentication data between parties. XML offers platform independence but can grow large and complex to parse.

In contrast, OIDC uses compact JSON data and JWT tokens carried within HTTP redirects. JSON is relatively simple to work with programmatically across languages.

2. Protocol Layers

SAML operates directly on top of transport protocols like HTTP, SMTP, and FTP without an intervening security framework.

OIDC enhances OAuth 2.0 authorisation capabilities with an identity layer, inheriting useful features like access tokens.

3. Transport Security

SAML typically uses XML signatures, encryption, and SSL/TLS for message-level security. This can introduce complex key management overhead.

OIDC entirely relies on underlying HTTPS TLS for secure communication, including protecting tokens using OAuth standards.

OIDC has a more lightweight protocol design better suited for modern applications and workflows. However, SAML offers more protocol-level configuration choices.

Architectural Differences

There are also some meaningful differences in how SAML and OIDC integrate identity capabilities into application architectures:

• Dependency: SAML depends on apps explicitly supporting the standard. OIDC can work by just delegating auth to external identity providers.
• User Experience: OIDC enables smoother UX through external IDP handling login screens. SAML redirects can feel disjointed.
• Identity Linking: SAML links identities across participating SPs. OIDC links identities from the identity provider side.
• Infrastructure: SAML requires dedicated IDP and SP setups with SAML compatibility. OIDC uses available social/enterprise identity providers.

These architectural differences make OIDC simpler to bootstrap, while SAML offers deeper identity integration across your domain.

Security Considerations

As security is paramount for identity protocols, how does SAML compare to OIDC on key aspects?

• Encryption: Both use transit-level encryption like TLS to secure communication channels. SAML also supports message-level encryption.
• Signatures: OIDC JWT tokens rely on OAuth standards for signing user identity claims. SAML signatures are built into the core XML protocol.
• Multi-Factor Authentication: SAML has direct support for OTP, biometrics-based MFA. OIDC can technically integrate MFA, but specification lags.
• Audit Logging: SAML logging and reporting capabilities are still more mature than the nascent OIDC ecosystem.

SAML offers richer protocol-level security capabilities, given its longer history. However, both standards are considered secure for internet-scale deployment.

Performance and Scalability

With cloud-native applications prioritising scalability, how do SAML and OIDC measure up?

• Latency Overhead: The XML processing in SAML transactions adds latency, which grows with larger SAML assertions. OIDC has lower latency.
• Bandwidth Overhead: The JSON payloads in OIDC minimise bandwidth overheads compared to heavy SAML XML documents, especially for mobile apps.
• Caching Support: OIDC builds on OAuth caching methods for tokens and responses, limiting calls to identity providers. SAML lacks native caching.
• Scale and Availability: Stateless JWT tokens make OIDC simpler to distribute across CDNs and cloud infrastructure. SAML sessions are tougher to scale.

The intrinsic lightweight nature of OIDC gives it better performance efficiency and scalability characteristics.

Governance Capabilities

Mature identity protocols need advanced capabilities to meet real-world governance needs:

• Per-Transaction Logging: Detailed audit logs are vital for security forensics. SAML's XML structure provides better transaction data capture.
• Federation Options: Both standards support identity federation. However, SAML is better suited for heavier federation constructs through its deep interlinking.
• Consent and Privacy Controls: OIDC aligns with OAuth to provide users with more consent options for data sharing. SAML focuses on enterprise needs.
• Administrative UIs: SAML products often have rich graphical interfaces for managing identity providers, rules, and more.

Conclusion

When evaluating OIDC vs SAML, it's clear they fulfil authentication needs differently. SAML powers enterprise SSO systems with XML, while OIDC offers a lightweight identity layer for modern apps via JSON.

For greenfield development, where scalability and agile platforms are key priorities, OIDC is the prudent default choice, given the ubiquity of OAuth providers. However, SAML remains relevant where complex enterprise ecosystem integration and strict governance are necessities.

Organisations need Multi-Factor Authentication that provides an additional layer of protection on employee and customer accounts.

Enabling multi-factor sign-ins with InstaSafe establishes resilient identity assurance so you can count on validated access to vital infrastructure and information systems.

Frequently Asked Questions (FAQs)

• What are the main differences between SAML and SSO?

SAML is an XML-based protocol that enables single sign-on across applications and services. SSO is the overarching concept for one-time authentication and access across platforms.

• What is the key difference between OIDC and OAuth?

OIDC builds an identity layer on top of the OAuth authorisation framework to handle user authentication, while OAuth focuses solely on enabling access delegation.

• Is SAML or OIDC more secure?

Both SAML and OIDC offer robust security protections for internet-scale deployments. SAML provides more built-in protocol-level security capabilities, while OIDC fully relies on the security of OAuth and HTTPS.