SAML vs OAuth

What’s the difference between SAML and OAuth? It’s a fairly common question for system administrators, security professionals, and application developers looking to improve their identity management posture and simplify the way users access resources with a common set of credentials.

As organizations ponder the two concepts, it would be helpful to have a guide to differentiate between the two. Here is your guide for contrasting SAML versus OAuth.

How Does SAML Work?

The Security Assertion Markup Language (SAML 2.0) is a standard authentication (and occasionally authorization) protocol which is most often used to simplify access to web applications via single sign-on (SSO).

Providers use SAML to relay credentials between an identity provider (IdP), which contains the credentials to verify a user, and a service provider (SP), which is the resource that requires authentication. Information about a user or group is stored within attributes. 

Let’s take a deeper dive into each of SAML’s main components:

Identity Provider

IdPs are services that create, maintain, and manage digital identities. They function as the single source of truth that verifies login credentials across applications, networks, and services. An IdP protects the integrity of user credentials and federates user identity across the web.

Client

This is the user that authenticates with credentials managed by an IdP, becoming an authenticated user on a service.

Attributes

SAML assertions are messages sent from an IdP to a service provider that are used to set security requirements for the transaction, as well as to authenticate, authorize, and determine the level of permissions to establish for each client.

Assertions contain attributes such as “department,” “email,” and “role,” which are used to enforce access management and control. Sometimes, custom attributes are used to work with specialized software.

Service Provider

Service providers receive and accept/deny assertions from IdPs for a client and grants access to whatever resource the user needs. SPs send requests to IdPs to begin the authentication process.

The client’s assertion is sent back in response. The order in which this happens is sometimes reversed with the IdP initiating the sign-in flow to assert user identity.

Now that we’ve covered the basics, here’s how it works as a whole. SAML uses extensible markup language (XML) metadata documents as its SAML tokens for an assertion of a user’s identity. The process of SAML authentication and authorization (AuthN and AuthZ) is as follows:

Developers can leverage SAML plugins to ensure their app or resource follows desireable single sign-on processes to simplify their user’s login experience and ensure security practices are laid in place to leverage a common identity strategy.

That way, only an identity with the proper credentials/assertion can access an application. Additionally, SAML can be used to control what an identity can access in an application. Access is only a user click away.

How Does OAuth Work?

OAuth, or Open Authentication, is also an AuthN/AuthZ protocol used for secure authentication needs. Like SAML, OAuth requires an identity provider as the source of truth for authenticating user access. OAuth uses its own XML documentation for authentication tokens, but can also use JavaScript Object Notation (JSON) for tokens as well. Here are its main components: 

Resource Owner

We’ve all signed into a service that offers to log you in using an existing credential from a large social media site versus creating a new account with credentials that are unique to that site. That social media account is yours, and you’re the resource owner.

Client

This is the site/application that utilizes the social media account you own (or whatever other account is listed as an option). It uses OAuth rather than storing your credentials and redirects the user to a login via an authorization server before it grants access.

Resource Server

A resource server is an API server that stores data that the client application is requesting. This server handles requests after the client application has been granted an access token.

Authorization Server

The authorization server is at the center of the OAuth workflows and grants consent, fielding requests for access and granting temporary tokens that a client “cashes in” at a resource server.

The OAuth process is detailed in the following diagram:

SAML vs. OAuth

In general, SAML and OAuth are very similar: they both authenticate and authorize access regarding applications hosted in a web browser. When it comes to practice, though, they are obviously very different.

Similarities

Both of these authentication patterns enable SSO to eliminate unnecessary usernames and passwords, scale well for the web, and are based on open standards to verify identities and grant access to protected resources through centralized management.

IT admins benefit from easier onboarding and delegated user management. The standards can even be complementary and encourage interoperability. For example, the OAuth assertion flow makes it possible for authentication servers to receive authorization grants from SAML-trusted IdPs.

Differences

Imagine that you’ve purchased tickets to a ballgame. SAML is akin to a ticket that a ticket taker authenticates upon entry, granting access to the venue until there’s a winner (or a tie). OAuth is the package that your ticket purchases: e.g., you’re sitting in a section that entitles you to private bathrooms, catering, and the like. You’re authorized to have those perks.

There are some privacy concerns associated with using third-party OAuth services. Governmental regulatory regimes, such as GDPR, require website operators to declare which services use and collect data. Organizations that use “free” OAuth services may lack autonomy and control, and the online activities of employees may be tracked by advertisers.

How Are SAML and OAuth Used?

SAML is designed for situations like web app SSO solutions, where a central identity provider and an app are in communication and SAML facilitates the AuthN/AuthZ between them. OAuth is generally used by the applications themselves, using external IdPs to authenticate access and authorize permissions.

Another way to think about the difference is that SAML can generally be thought of as user centric whereas OAuth tends to be more application centric. For example, a user will log in to their single sign-on service and subsequently have access to their roster of SAML-based applications.

With OAuth, a user will generally authenticate with each individual service and the application will have a one-to-one mapping with an IdP.

When it comes to an organization’s identity management, both authorization protocols are useful, and, while not quite usable in concert, they can coexist peacefully. Because of that, however, it might be difficult to find an option for SAML and OAuth AuthN/AuthZ that isn’t a one-off point solution.

OAuth is more tailored toward access scoping than SAML. Access scoping is the practice of allowing only the bare minimum of access within the resource/app an identity requires once verified. For instance, OAuth is often used when a web browser requests access to your system’s microphone and camera.

This makes OAuth (specifically OAuth2) ideal for web/mobile apps, especially ones that can use Google, Facebook, or some other similar identity provider as a source of truth.

Can SAML and OAuth Be Used Together?

There is an option available, a cloud directory service, that organizations can use to facilitate both SAML and OAuth usage for identity management. This solution is called the JumpCloud Directory Platform, the first cloud directory service and identity provider. 

JumpCloud natively uses the SAML protocol to directly communicate with hundreds of applications a la single sign-on. JumpCloud also directly integrates with Google Workspace and Office 365 identities, meaning that it can control application access through OAuth as well, leveraging those sign-in mechanisms (e.g., “Sign in with Google”) using OAuth under the covers. JumpCloud provides Push and TOTP MFA services to add another layer of authentication.

Beyond SAML and OAuth, JumpCloud also provides an additional array of standard authentication and authorization mechanisms such as LDAP and RADIUS to ensure users can leverage a single set of credentials across all of their resources ranging from web apps to on-prem resources like NAS appliances or legacy applications.

The credentials also are leveraged for secure access to their macOS, Windows, and Linux systems, ensuring the greatest totality of coverage a user’s identity can access securely. And, since it is a centralized identity provider with these capabilities, it offers admins the ability to provide their users with a single set of credentials to access all of these resources, all managed from a single cloud admin portal.

Learn More

If you would like to learn more about SAML, OAuth, and JumpCloud in general, please contact us. You can also explore what JumpCloud has to offer by scheduling a free personalized demo.