SAML vs. OAuth - Understand Differences and Benefits

By James Konik

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.

What Are Common SAML and OAuth 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.

What Is Security Assertion Markup Language (SAML)?

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:

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.

What is Open Authorization (OAuth)?

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.

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

What Are the Differences Between SAML and OAuth?

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.

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.

You can experiment with OAuth on the OAuth Tools website.

What are Some Typical Use Cases for SAML and OAuth?

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

Typical SAML Use Cases

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.

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.

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.

Large Cloud Platforms

Large cloud platforms often allow users to sign in via SAML, letting admins easily assign roles and permissions.

Typical OAuth Use Cases

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.

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.

Mobile Devices

Mobile users can access OAuth-enabled applications with existing credentials.

Device Authorization

OAuth device authorization allows you to authenticate on consumer devices.

Single-Page Applications

Single-page applications (SPAs) contain all their logic on the frontend. That makes regular authentication difficult.

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.

FusionAuth supports both protocols, allowing you to use them where appropriate.