Feb 22, 2024
Table of contents
SAML (Security Assertion Markup Language) and OAuth (Open Authorization) are both open standards that are used within identity management to handle authentication and authorization. Organizations including OASIS and the IETF (Internet Engineering Task Force) help to develop, publish, and maintain protocols such as SAML and OAuth.
SAML and OAuth perform different functions: SAML is used mainly for authentication (that is, to validate user identities) but can be used for authorization, whereas OAuth by itself is only designed for authorized access to resources without sharing the resource owner’s credentials.
Why are protocols needed in an IAM system?
Identity and Access Management (IAM) systems rely on standardized protocols to ensure secure, scalable, and interoperable authentication and authorization across applications and services.
Protocols define how identity-related data, such as login credentials or user attributes, is exchanged between trusted parties like:
Identity providers (IdPs), which verify user identity
Service providers (SPs), which grant access to protected resources
Using open standards reduces complexity, increases compatibility, and supports secure federation across cloud and hybrid environments.
What is SAML?
SAML is an XML-based protocol used for single sign-on (SSO) in enterprise and educational environments. It enables users to authenticate with an identity provider once and access multiple service providers without re-entering credentials.
Here’s how it works:
The identity provider (IdP) authenticates the user
A SAML assertion, a digitally signed XML token, is generated and passed to the service provider (SP)
The SP uses the assertion to verify the user's identity and grant access
SAML is often used to provide secure access to productivity tools, enterprise SaaS platforms, and partner portals.
What is OAuth?
OAuth 2.0 is an authorization framework designed to give third-party applications limited access to user resources without exposing login credentials.
Key concept: Access tokens, typically JSON Web Tokens (JWTs), are issued by an authorization server and used by clients to access data from resource servers. OAuth is designed for flexible delegation scenarios, such as:
Mobile apps accessing a user’s cloud storage
Third-party calendar integrations
Smart device pairing flows
OAuth is not an authentication protocol by itself but is often extended by protocols like OpenID Connect (OIDC) to support user authentication.
History of SAML
SAML is a veteran authentication protocol, first published as an open standard by OASIS in 2002. One of the most successful implementations of federation and SAML SSO is in higher education, with the Shibboleth initiative and the Liberty Alliance’s Identity Federation Framework. OASIS released SAML 2.0 in 2005, and the protocol is still in use today. However, SAML is increasingly being replaced by the more modern identity protocol, OpenID Connect (OIDC), which is built on top of OAuth.
History of OAuth
OAuth was originally devised to solve an issue with delegated authentication. OAuth 1.0 was released as an open standard in 2010 and published by the IETF. By 2012, OAuth 2.0 had been released. Since then, OAuth 2.0 has found massive uptake; it’s used by companies such as Google, Amazon, Facebook, LinkedIn, Microsoft, and Netflix.
How does SAML 2.0 work?
The main components of the SAML system are:
User (principal): The person attempting to access a resource
Identity provider (IdP): Authenticates the user and issues assertions
Service provider (SP): Accepts assertions and grants accessSAML 2.0 handles the communication between an IdP and the SPr.
A SAML assertion is a message exchanged between an IdP) and the SP. SAML assertions underpin the SAML workflow. However, the communication must be trusted. SAML-based services use secure onboarding that requires the sharing of specific endpoints, metadata, and digital certificates to add trust. Once trusted onboarding of the IDP and SAML SP is established, the SAML authentication request and response process can begin.
SAML requires trusted metadata exchange between IdPs and SPs. This includes:
Endpoints
Public keys
Signing certificates
Once trust is established, the SAML assertion acts as the vehicle for federated SSO.
SAML Workflow
The SAML workflow below is based on the exchange of a SAML assertion:
User wishes to access an SP.
The SP initiates a SAML authentication request.
The browser redirects this SAML authentication request to the IdP.
The user is asked to login to the IdP and give consent to share attributes, and so on, as requested by the SP.
Successful login generates a SAML token response back to the SP.
If the SP accepts the SAML response, the user will be logged into the service provider.
SAML provides the means to deliver federated authentication SSO, which links user identities across multiple identity management systems.
SAML Workflow
The user attempts to access a service provider (SP)
The SP redirects the browser to the identity provider (IdP)
The IdP prompts the user to log in (if not already authenticated)
Upon successful login, the IdP sends a signed SAML assertion to the SP
The SP validates the assertion and grants access to the user
This entire process is seamless to the user and supports SSO across multiple domains.
How does OAuth 2.0 work?
The main components of an OAuth 2.0 system are:
Resource owner: The user or system that owns the resources and can grant access (consent).
Client: The system that requires access to the resource.
Authorization server: Receives requests from the client for access tokens and issues access tokens to the client on successful authentication and consent by the resource owner.
Resource server: Accepts and validates access tokens.
OAuth handles authorization requests and responses between services while ensuring the confidentiality of user credentials. However, OAuth 2.0 has several different flows called grant types.
These grant types have different use cases. Three commonly used grant types are:
Authorization code: Involves a single-use access code, which is then exchanged for an access token.
Authorization code with PKCE: Can be used for mobile apps and native apps, as well as single page apps.
Device authorization flow: For use by apps on devices where input is constrained, for example, smart TVs.
OAuth Workflow
There are several grant types for OAuth 2. The steps below show a service requesting access to a user’s email address and profile picture:
The user wishes to access a service.
The user is redirected to the authorization server that maintains the user’s resources.
The user is asked to sign in and consent to the access of the resources requested by the service provider.
If consent is provided, the web browser is redirected back to the service with an access code.
The service then exchanges the access code for an access token.
The service uses this token to request the user’s email and profile picture.
SAML use cases
Single sign-on (SSO): SAML enables federated authentication SSO across multiple applications and services. Employees can authenticate once with their corporate credentials to access federated applications without re-entering their credentials.
Access to cloud-based apps: SAML secures access to cloud-based applications and services. SAML can be used for inter- and intra-organizational access control. This allows organizations to maintain control over user authentication while providing access to external users such as supply chain members.
Cross-organizational secure collaboration: SAML can be used to secure collaboration between organizations using identity federation.
OAuth use cases
Consented sharing between third-party apps: A user may want to allow a third-party app to access assets, such as email addresses, from a different data store. OAuth provides the means to share this data without sharing the user’s login credentials. Federated social media login typically uses OAuth 2.0 for this use case.
Smart TVs and similar devices: OAuth Device Flow provides the protocol rails to connect limited-input devices with online services and APIs.
API gateways: OAuth 2.0 can be used to control access to APIs. The gateway becomes an authorization server and issues access tokens to clients. Then, when a client requests access to an API, the gateway verifies the access token, allowing access if the token is valid.
Who uses SAML?
SAML remains relevant in 2025 in sectors where federated SSO is key. These include:
Government services like Login.gov
Large enterprises with on-prem or hybrid identity systems
Education institutions federating access across campuses
Most major identity providers, including Azure AD, Okta, and Ping Identity, still support SAML 2.0.
Who uses OAuth?
OAuth 2.0 is nearly ubiquitous for authorization on the internet. Used by:
Newer standards built on OAuth:
OpenID Connect (OpenID Foundation)
UMA 2.0 (Kantara)
IndieAuth (W3C)
What’s Google Sign-In?
Integrating Google Sign-In is widespread on the web and is based on OAuth. It provides simplified registration and sign-in. Users who are signed in to Google on a device or browser can then get fast authentication on a web application or website that supports Google Sign-In. Automatic one-tap sign-in for returning users is also supported. New account registration is simplified by federating with Google Sign-In.
Google has made the integration with Sign-In simple by supplying client libraries for developers. Using client libraries allows a web developer to hand off the management and handling of the OAuth 2.0 flow and token lifecycle to Google. This simple integration and the improved user experience of sign-in and registration have resulted in 3,827,591 websites using Google Identity Platform and Sign in with Google.
Key benefits:
One-tap login for returning users
Fewer passwords to manage
Easy integration using Google’s client libraries
As of early 2025, more than 4 million websites use Google Identity Platform and Sign in with Google, making it one of the most widely adopted authentication services online.
