SAML vs. OAuth - Understand Differences and Benefits

Login is the first major step in your relationship with your users. Making it go smoothly reflects well on your applications. It also needs to be secure, but the requirements for identifying users safely are complex.

Using a defined protocol lets you give users a secure, established process for accessing privileged resources. SAML and OAuth are two systems that make allowing access more convenient and secure. Although they’re superficially similar, under the hood there are more differences than you might expect.

OAuth was originally developed by engineers from Google and Twitter. It lets you use login credentials for large sites—like Google or Twitter—to log in to other applications. That means you can carry the same credentials around the internet instead of having to create new ones for each site you visit.

SAML, or Security Assertion Markup Language, also lets you log in to multiple sites using a single sign-on, or SSO. It delivers assertions in XML that give information to authenticate users. Assertions can also include attributes or authorization decisions.

SAML is primarily an authentication system, while OAuth is an authorization system. Authentication is about confirming the user’s identity. Authorization is about deciding what services they can access.

Workflows

Let’s take a look at how the two systems let you access websites and applications. These are common systems, though other workflows are possible.

Security Assertion Markup Language (SAML) Definition

When a user interacts with SAML, both a service provider and identity provider are involved. The service provider is typically the website the user is interacting with.

If the user tries to access a protected resource, or tries to log in, the service provider sends the browser a SAML request, which the browser then uses to connect to the identity provider. The SSO service asks the user for credentials, and the user provides their login details, such as a username and password.

Here’s a diagram showing how single sign-on works:

Diagram showing flow between the user apps and identity provider when using multiple applications.

When the right credentials are provided, the identity provider responds with a SAML response indicating what level of access the user has the rights to. The user can then pass these details to the service provider to use their services.

If the user is already authenticated, they’re not asked for their credentials, which saves time and improves the user experience.

Open Authorization (OAuth) Definition

There are two versions of OAuth, and there are differences between them. This article focuses on version 2.0, which has been around since 2012. An updated version 2.1 has been proposed but not yet approved.

With OAuth, a user making a login or resource request is redirected to an authorization server, which is run by a company like Google, Twitter, or Facebook. Companies can also run their own authorization server. The authorization server presents the user with a familiar login screen. However, the login screen won’t grant access directly to that service. Rather, it allows the site making the redirect to access the user’s data supplied by that service.

There are several possible workflows with OAuth. In the deprecated implicit grant, when the user provides appropriate credentials, the authorization server provides them with an access token and redirects them to a URI originally supplied by the client.

In the authorization code grant workflow, the authorization server redirects the user back to the original application with a code in the URI. That application requests an access token from the authentication server, using the code and their own secret credentials.

Since this grant avoids always sending the access token directly to the client, you have more architectural flexibility. In addition, you don’t send the token over an accessible channel like the URL query string, which prevents malicious access if the user’s device is compromised.

Access tokens are typically in JSON Web Token (JWT) format, but can be in other formats as well, even regular text.

JWT Debugger is a tool that shows you how the token and the information it contains relate to each other:

JWT Debugger tool on FusionAuth website showing typical content and resulting token.

The access token is then sent to the resource server, which verifies it with the authorization server before providing access to the user.

This allows users to gain access through a familiar UI, and their primary credentials are shared only with a service they already know and trust. The resource owner gets to take advantage of the authorization platform’s established systems and recognition. The authorization provider gets its service used more widely, and may also benefit from getting added information about the user’s activities.

This information is a core source of revenue for companies like Facebook. While some users may not be keen on the potential lack of privacy, those users are in the minority. However, these concerns are part of why some companies are choosing to run their own OAuth servers.

Comparison of OAuth and SAML

Let’s talk about what function each system performs.

SAML is primarily for authentication, which means proving the user is who they say they are.

There are several common places where we see this in action. While entering a username and password is the most obvious example, unlocking your phone with a passcode or using a biometric scanner are also forms of authentication. With SAML authentication, the identity provider returns a SAML response confirming the user’s identity.

OAuth, by contrast, is an authorization system. Here, the system determines what permissions the user gets.

Though authentication and authorization are different, they’re often used together, with one system for each type of functionality. Apps often need to both authenticate users and then determine what they can do, though in some cases, such as logging into a streaming service or other subscription-based platform, authentication might simply grant them access to resources.

OAuth is frequently used together with OpenID Connect, or OIDC. This allows you to authenticate users and get their profile information, such as contact data or personal details, while using OAuth for authorization.

You can experiment with OAuth on the OAuth Tools website, as in the screenshot below:

Refresh token demo from OAuth Tools.

SAML, though an authentication-based protocol, can also be used to provide other information, and these attributes can be used to provide role information, providing authorization functionality.

Using OAuth for authorization together with SAML for authentication is perfectly feasible. The Microsoft identity platform, for example, uses them both.

Typical Use Cases

Let’s look at some of the ways these systems are used.

SAML

SAML allows users to conveniently access multiple resources safely and securely. It can reduce support requests since users don’t need to create and store credentials for every service they use. It tends to be popular with groups that need to regularly grant access to specific sets of resources, as it minimizes the work involved.

Enterprise Access

SAML is widely associated with large organizations. You can use it to provide users with access to a system, and use its attributes to control what exactly they can do. You can also use attributes to group users, and then dynamically adjust what they have access to.

Single Sign-On between Separate Platforms

Single sign-on (SSO) is SAML’s most common use, allowing users to authenticate across multiple domains without needing new credentials each time.

If your company uses SAML, it can assign you credentials that work with other platforms you’ll need at work, such as Salesforce or Jira.

Large Cloud Platforms

Large cloud platforms often allow users to sign in via SAML. In addition to being convenient, it lets admins easily assign roles and permissions. Different team members get access to the appropriate resources, and changes to roles are easy to make.

Zendesk is a typical example. You can add attributes to SAML-enabled users, allowing you to store things like contact details, team membership, access levels, or whatever other data you require.

OAuth

OAuth allows developers to authenticate users without demanding their credentials. This lets them learn more about their users, but doesn’t require that users create a new login or provide details they’ve entered elsewhere. Perhaps more importantly, it also means developers can provide key functionality without having to build it themselves.

Web Applications

If you’re building an app, you can use OAuth to let users access it securely, regardless of what framework you’re using. Getting security right is hard, but integrating a pre-existing solution doesn’t have to be.

For example, if you’re developing a React app, you can rely on OAuth to grant users access.

Using a third-party authorization system can make the development of secure applications faster and easier. Logging in with Facebook or Google makes your site more attractive to users who trust those brands, and lets them avoid the friction point of having to create new credentials.

Mobile Devices

Mobile users can access OAuth-enabled applications with existing credentials. Since they log in via the OAuth provider, their data is kept private from the application they’re logging in to.

Dealing with multiple passwords is fiddly and awkward on mobile, and storing them is a security risk. Using a social login solves those problems.

There are established security best practices when using OAuth with mobile, such as not using embedded views with third-party applications. You can also use PKCE, or Proof Key for Code Exchange, to add further protection against some types of attacks.

Device Authorization

OAuth device authorization allows you to authenticate on consumer devices. If you’re using Apple TV, a game console, or a similar smart device, entering login details is awkward and error-prone.

With OAuth device authorization, your smart device shows you a URL and a code. You use another device such as a PC or smartphone to access the URL, sign into the relevant service, and add the code.

The smart device can detect this, and then you’re authorized. It’s quick and easy, and saves you from having to enter your login data on the original device.

Single-Page Applications

Single-page applications (SPAs) contain all their logic on the frontend. That makes regular authentication difficult. All the code for an SPA runs in the browser, so client secrets can’t be kept confidential.

You can sidestep this problem by using OAuth with a backend for frontend (BFF) component. The component can manage OAuth tokens for your SPA using encrypted, same-site cookies.

Conclusion - When Should You Use SAML or OAuth?

SAML and OAuth are different solutions to similar problems. They’re different animals, but their territories overlap at times, and you can frequently find them together.

Understanding what they offer helps you choose which to use, and when.

For modern applications deploying across multiple devices, the flexibility and ease of use of OAuth make it a winner. If you augment it with OIDC, you get the benefits of secure authentication and authorization with easily implemented third-party services.

SAML is sometimes more practical for large organizations in enterprise scenarios, enabling your users to access multiple services conveniently. However, the complexity and age of the specification and the use of XML as the transport layer can make it more difficult to use SAML.

FusionAuth supports both of these important protocols. FusionAuth can be used as both SAML identity provider and service provider and as an OAuth and OIDC authorization server and resource server. However, in general, if you have the choice, you should use OAuth paired with OIDC, as it is the more modern protocol and is continually improving. Use SAML where you are required to.