In the world of digital identity and security, protocols like SAML (Security Assertion Markup Language) and OAuth (Open Authorization) play crucial roles. While they may seem similar in some ways, they serve different purposes and are used in various scenarios.

In this blog post, we'll explore the differences between SAML and OAuth, providing clear examples of each.

SAML: Enabling Single Sign-On (SSO)

SAML, or Security Assertion Markup Language, is a protocol designed for single sign-on (SSO) and exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). Its primary purpose is to enable users to log in once and access multiple services without repeatedly entering their credentials.

Example of SSO

Imagine an employee working for a company that uses SAML. The employee wants to access various applications like email, CRM, and the HR portal.

Instead of logging in separately to each of these services, the employee logs in once using their corporate credentials at the IdP (e.g., Active Directory). The IdP generates a SAML assertion, which is then sent to each service provider (SP). This allows the user to seamlessly access these services without the need for multiple logins.

OAuth: Delegated Authorization

OAuth, or Open Authorization, serves a different purpose. It's primarily used for delegated authorization, allowing third-party applications to gain limited access to a user's resources without the user having to share their credentials. This makes it an ideal choice for scenarios where users want to grant permissions to external apps.

Example of OAuth

Let's consider a user who wants to give a social media app access to their photos stored in a cloud storage service, such as Google Photos.

OAuth facilitates this process. The user authorizes the app (referred to as the client) to access their photos by obtaining an access token. This token serves as the app's credential, allowing it to make API requests on behalf of the user, retrieving their photos from the cloud storage service without compromising their login credentials.

Key Differences at a Glance

Feature SAML OAuth
Primary Purpose Authentication & SSO Delegated Authorization
Protocol Type XML-based Token-based (JSON)
Use Case Enterprise SSO across internal apps Third-party app access to user resources
Token Format SAML Assertion (XML) Access Token (JWT/opaque)
Best For Corporate environments Consumer-facing APIs and apps

SAML and OAuth/OIDC in Microsoft Entra ID

If you're implementing either protocol on Microsoft Entra ID (formerly Azure Active Directory), the practical guidance is:

  • SAML apps are configured under Enterprise applications in the Microsoft Entra admin center -- this is the path used for most pre-built SaaS SSO integrations that only speak SAML.
  • OAuth 2.0 / OpenID Connect apps use an App registration, giving you an application (client) ID, redirect URIs, and token configuration for modern web, mobile, and API scenarios.
  • Microsoft's own guidance is to use OpenID Connect and OAuth 2.0 for any application that supports it, and reserve SAML for legacy applications that only support SAML. See Microsoft's SAML versus OpenID Connect decision guide for the full comparison.
  • Conditional Access policies (MFA, device compliance, location, risk-based access) apply at sign-in regardless of which protocol the app uses -- Entra ID enforces Conditional Access before issuing either a SAML assertion or an OAuth/OIDC token.

In Summary

While SAML and OAuth are both essential for managing authentication and authorization, they have distinct purposes and use cases:

  • SAML is all about Single Sign-On (SSO) and identity federation, simplifying the login process for users across multiple services.
  • OAuth, on the other hand, focuses on delegated authorization, making it possible for third-party applications to access user resources with limited permissions.

In modern identity and access management systems, these two protocols are often used in tandem to create a robust solution that combines the benefits of SSO with the ability to grant fine-grained access to external applications.

Understanding the differences between SAML and OAuth is crucial for designing secure and efficient authentication and authorization systems.

Frequently Asked Questions

Can SAML and OAuth be used together?

Yes, many organizations use SAML and OAuth together. SAML handles the initial authentication and SSO, while OAuth manages authorization for API access and third-party applications. For example, a user might authenticate via SAML SSO and then use OAuth tokens to authorize a third-party app to access their calendar data.

What is the difference between OAuth and OAuth 2.0?

OAuth 2.0 is a complete rewrite of the original OAuth 1.0 protocol. OAuth 2.0 is simpler to implement, supports more grant types (authorization code, client credentials, etc.), and is the standard used today. OAuth 1.0 is considered obsolete and should not be used for new implementations.

When should I use SAML instead of OpenID Connect (OIDC)?

SAML is typically used in enterprise environments with legacy applications that already support SAML. OpenID Connect (OIDC), which is built on top of OAuth 2.0, is preferred for modern web and mobile applications because it is simpler, uses JSON instead of XML, and has better support for mobile and SPA (single-page application) scenarios.

Is OAuth secure for authentication?

OAuth was designed for authorization, not authentication. Using OAuth alone for authentication can introduce security vulnerabilities. For authentication, you should use OpenID Connect (OIDC), which adds an identity layer on top of OAuth 2.0 with ID tokens that verify the user's identity.

What is a SAML assertion and how does it work?

A SAML assertion is an XML document issued by the identity provider (IdP) after a user successfully authenticates. It contains statements about the user's identity, attributes, and authorization decisions. The service provider (SP) validates the assertion's digital signature and uses the information to grant the user access without requiring a separate login.

Related Reading