SAML vs OAuth: Key Differences Explained
The choice between SAML and OAuth isn’t a “this” or “that” conversation. While SAML and OAuth may appear to be alternatives or interchangeable at face value, they serve distinct use cases.
If your engineering or IT team needs to centralize how employees access multiple internal and SaaS applications using a single set of credentials, SAML is what you need to implement. On the other hand, if you need to manage and secure how your APIs, service accounts, machine-to-machine (M2M) applications, microservices, or IoT devices interact, you should implement OAuth 2.0.
In this article, we’ll cover the fundamentals of SAML and OAuth, including their architectures, data structures, auth flows, applications, and use cases. Whether you're a senior developer or just starting out, this guide will provide the clarity you need to confidently work with either of these protocols.
Understanding SAML and OAuth
At a high level, SAML (Security Assertion Markup Language) is an enterprise SSO protocol, while Open Authorization (OAuth) is a delegated authorization protocol.
What is SAML (Security Assertion Markup Language)
SAML is designed to support single sign-on (SSO) in enterprise and highly-regulated environments. It enables the exchange of authentication and authorization data between a dedicated identity provider (IdP) and multiple service providers (SPs). In this way, users and employees don’t have to maintain individual login credentials across all the systems they need to access for work.
Instead, these enterprise users only need to own a single set of credentials with the IdP used within their organization to manage user profiles and identity data (e.g., Okta, Entra ID, One Login, Google, etc.). These IdP-provisioned credentials can then be used to access multiple SPs (e.g., GitHub, Vercel, Slack, Figma, etc.) via SSO.
What is OAuth (Open Authorization)
OAuth is an open delegation standard for granting secure access to resources without sharing user credentials. It enables clients or third-party applications to request permission from a resource owner (a user) via a resource server in order to gain access to a protected resource on the owner’s behalf.
The resource owner is the delegating party and is typically an end-user on whose behalf the client intends to act. The owner maintains control over which resources the client can access, the permissions or actions it can perform, and can also revoke this access at any time.
On the other hand, the client or third-party application is the delegated party and could be an API, microservice, or any kind of system capable of requesting access. While the protected resource could be data, permissions, or actions that can be performed on an API, an application, or even a database.
The resource server is any server that hosts the protected resource and is capable of validating the access tokens issued by an OAuth 2.0 Authorization Server. The client must obtain a client ID and secret from the authorization server before sending requests to the endpoints specified by the server.
It’s important to note that client authorization via OAuth 2.0 is very different from impersonation because the requesting client must verify their identity and also request permission from the authorization server in the form of an access token.
For example, let’s assume you intend to link your USD bank account to a wallet service like PayPal, Cash App, or Zelle using an open banking provider like Plaid. When you initiate the connection, Plaid authenticates your bank credentials to ensure you own the account, then uses OAuth 2.0 to issue an access token to the wallet service. This token allows the wallet service to securely access your bank information, such as your account balance and transaction history, without needing your login credentials. In this scenario, Plaid acts as the authorization server between your bank and the wallet service—you’re the resource owner, your bank is the resource server, and the wallet service is the client requesting access.
Authentication and authorization in SAML vs. OAuth
SAML is primarily a user authentication protocol, but it can also support authorization because user roles and permissions can be included in SAML assertions as attribute and authorization statements. These SAML statements can be used to indicate whether a user is permitted to access a particular resource and the actions they’re allowed to perform.
However, this doesn’t mean SAML can replace traditional authorization and access control frameworks such as RBAC, ABAC, and PBAC. This clarification is important because it's easy to confuse SAML for a typical user authorization framework.
For example, the user attributes included in a SAML assertion can be used as input attributes by ABAC systems that need to make access control decisions. However, these SAML attributes can’t replace the policies, conditions, and other components like the decision points, enforcement points, and retrieval points that form the core of a full-fledged ABAC authorization system.
On the other hand, while OAuth is primarily a client authorization protocol, it also performs client authentication. This means a client that needs to access a protected resource via an OAuth 2.0 server must first verify its identity using a client ID and secret (client authentication) before it can be granted access to the resource using access tokens (client authorization).
However, unlike SAML, OAuth doesn’t directly support user authentication. Instead, OpenID Connect (OIDC) was built on the core tenets of OAuth 2.0 to support user authentication using tokens. OIDC is an open identity standard that enables users to log into multiple OIDC-compliant systems using a single set of credentials that must have been provisioned on an OpenID provider.
Can SAML and OAuth be used together?
SAML and OAuth can indeed be integrated within the same system, but they serve different purposes and are not interchangeable. At best, SAML can be used to authenticate a client’s identity within an OAuth 2.0 authorization flow, as defined by the official IETF RFC 7522 specification.
This means client applications can exchange valid SAML assertions with an OAuth 2.0 server in order to obtain access tokens and perform actions on a user’s behalf. This approach is particularly useful in scenarios where SAML handles user authentication, and OAuth secures access to internal services or APIs. However, it’s important to note that this kind of SAML and OAuth integration only works in web-based scenarios, because SAML isn’t compatible with the wide range of application types and use cases that OAuth supports.
SAML architecture vs. OAuth architecture
SAML’s architecture is based on a request-response model, where a service provider (SP) sends a user authentication request (AuthnRequest) to an identity provider (IdP), which then sends the SP a response containing assertions about the authenticated user. These SAML requests and responses are digitally signed, encrypted, and communicated over secure HTTP POST and HTTP Redirect bindings.
In contrast, OAuth’s architecture follows a grant-token model. Here, the requesting client must obtain a permission grant from the end user before being issued an access token by the OAuth 2.0 authorization server. This token can then be used to gain access to the protected resource hosted on a resource server. While OAuth 2.0 doesn’t inherently encrypt requests and tokens, it mandates the use of opaque tokens and ensures all client-server interactions occur over secure HTTPS/TLS channels.
SAML data structure vs. OAuth data structure
SAML’s XML-based data structure
SAML requests, responses, and assertions are structured using XML (Extensive Markup Language). This XML-based format allows for the transmission of complex and detailed information, including nested elements, signatures, and attribute statements that define the authentication and authorization status of a user. While XML enables rich, hierarchical data representation, it can be verbose and complex to parse, especially for resource-constrained devices or lightweight applications.
Here's a simplified example of a SAML assertion structure:
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
Version="2.0"
IssueInstant="2023-07-30T09:30:10Z">
<saml:Issuer>https://idp.example.com</saml:Issuer>
<saml:Subject>
<saml:NameID>john.doe@example.com</saml:NameID>
</saml:Subject>
<saml:Conditions
NotBefore="2023-07-30T09:30:10Z"
NotOnOrAfter="2023-07-30T10:30:10Z"/>
<saml:AuthnStatement
AuthnInstant="2023-07-30T09:30:10Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="email">
<saml:AttributeValue>john.doe@example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="role">
<saml:AttributeValue>admin</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
This sample SAML assertion includes basic elements such as the issuer, subject, conditions, authentication statement, and attribute statement. In reality, SAML assertions often include additional elements and are typically much longer, especially when including digital signatures and encryption. However, SAML's detailed XML structure is what makes it suitable in enterprise SSO scenarios that usually deal with rich identity data.
OAuth’s JSON-based data structure
Unlike SAML, OAuth uses a much simpler data structure centered around tokens—primarily the access token and optionally the refresh token. These tokens are typically compact strings, often in the form of JSON Web Tokens (JWTs), which are more lightweight compared to SAML assertions. OAuth tokens contain minimal information, usually just an identifier or a set of claims, and are meant to be opaque to the client. The actual user information and additional metadata are typically stored on the server side and retrieved as needed using the token.
Here's an example of a decoded JWT structure used as an OAuth access token:
{
"header": {
"alg": "HS256",
"typ": "JWT"
},
"payload": {
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022,
"exp": 1516242622,
"scope": "read write"
},
"signature": "..."
}
This lightweight structure makes OAuth tokens easier to transmit and process, particularly in mobile and web applications, and APIs. The JWT can be easily encoded into a compact, URL-safe string for transmission.
SAML authentication flows vs. OAuth grant types
SAML authentication flows are primarily designed for web-based SSO scenarios and involve two main flows—SP-initiated SSO and IdP-initiated SSO. In the SP-initiated SSO flow, the user requests access to some protected resource from the service provider (SP) and is redirected to the identity provider (IdP) with an AuthnRequest. The IdP then authenticates the user’s identity and sends them back to the SP with a SAML response containing an assertion.
In contrast, the IdP-initiated SSO flow starts at the IdP, where the user authenticates their credentials and selects the SP they intend to access. The IdP then sends the user to their chosen SP with a SAML response and assertion, eliminating the need for an initial AuthnRequest from the SP. We’ve covered the key differences between the SP-initiated and IdP-initiated SSO flows in more detail here.
OAuth, on the other hand, provides several grant types/flows that cater to different use cases and applications, including web apps, SPAs, mobile apps, and APIs. The Authorization Code Grant is commonly used for server-side applications, where the client exchanges an authorization code for an access token. The Implicit Grant is used for browser-based applications, where the access token is directly returned to the client. Other grant types include the Client Credentials Grant, which is used for machine-to-machine communication, and the Resource Owner Password Credentials Grant. You can read more about these OAuth 2.0 grant types in our “What is OAuth 2.0?” article.
How SAML and OAuth approach security
SAML relies on XML signatures and X.509 certificates to secure messages exchanged between SPs and IdPs. Both SAML requests and responses can be digitally signed, enabling the receiver to verify that the message hasn’t been altered and originates from a trusted source. To achieve this, SAML uses XML Digital Signatures (XML-DSig) and applies cryptographic algorithms such as RSA combined with SHA-1 or SHA-256 for signing SAML messages.
Additionally, SAML assertions contain validity periods defined by NotBefore and NotOnOrAfter attributes. These attributes help mitigate replay attacks by ensuring assertions can’t be reused outside their designated time frame.
In contrast, OAuth ensures security primarily through the use of secure transport channels (HTTPS/TLS) and opaque tokens. When a client requests an access token from an authorization server, the communication must occur over HTTPS to protect the confidentiality and integrity of the data exchanged.
On the other hand, access tokens/JWTs are signed using algorithms like HMAC-SHA256 or RSA-SHA256 that ensure their integrity. These tokens are also designed to be short-lived and carry minimal information, usually just an identifier or a set of claims that specify the token’s scope and expiration, limiting the potential damage if tokens are intercepted.
Additionally, OAuth supports token expiration and refresh tokens that also help to enhance the security of the protocol. For example, when an access token expires, the client can use a refresh token to obtain a new access token without re-authenticating the user. OAuth also supports token revocation, which allows authorization servers to invalidate tokens if they are compromised or if the user's permissions change, thereby providing an extra layer of security.
To mitigate against common vulnerabilities, OAuth uses state parameters to prevent Cross-Site Request Forgery (CSRF) attacks, and implements strict redirect URI validation to mitigate open redirect vulnerabilities. For public clients, such as single-page applications, OAuth 2.0 recommends the use of Proof Key for Code Exchange (PKCE) which helps to prevent authorization code interception attacks.
Implementing SAML and OAuth using Stytch
Ready to implement SAML and/or OAuth in your project? Our documentation can guide you all the way from implementation to live.
Feel free to check out our SAML SSO docs to learn how to support SAML across multiple IdPs such as Google Workspace, Okta, and Microsoft Entra ID.
To protect your APIs and service accounts using the OAuth 2.0 Client Credentials Grant flow with Stytch as your OAuth provider, refer to our M2M docs.
If you have any questions about our features and pricing, please reach out to us at support@stytch.com or schedule a call with a member of our Solutions Engineering team.
Share
