SAML vs. OAuth: Side-by-Side Comparison

Security assertion markup language (SAML) and open authentication (OAuth) are two key aspects of access management. 

They’re both open standard protocols. But each one has a slightly different goal. 

SAML and OAuth can both be used for single sign-on (SSO) access, but SAML handles authentication and OAuth handles authorization. 

In short, SAML and OAuth are not interchangeable technologies. This guide will help you determine whether SAML or OAuth is right for you and your business.

Our Recommendation = Get OAuth

The vast majority of corporations, enterprises, and businesses of all sizes will benefit the most from OAuth. According to a study from TechRepublic, the average employee switches between 35 different job-critical applications over 1,100 times per day.

OAuth makes it possible for users to switch between one application or service and another without requiring a login for each account. 

The “auth” in OAuth refers to authorization. OAuth protocols make it easy for an employee to seamlessly navigate between apps without using multiple logins, all while protecting their usernames and passwords. 

In addition to the security benefits of using OAuth, it’s a huge time-saver for business productivity. The technology also keeps employees happy.

Even if you’re running a smaller business and your staff is only using five different job-critical applications on a daily basis, that’s still five different usernames and passwords they need to remember. Most people will just reuse the same usernames and passwords across multiple accounts. This is obviously a big gamble from a security perspective because if one account gets compromised, they’re all compromised. 

Let’s say your company uses Google Workspace. Anyone on your staff with an active Google account could use those same credentials to access apps like:

• Asana
• Agorapulse
• Hootsuite
• Microsoft 365
• SurveyMonkey
• Box
• Marketo
• Crazy Egg

The list is seemingly never-ending. With a single sign-on to one account, users can access CRMs, social media platforms, project management tools, and other various tools for job-specific activities. The OAuth protocol is what’s used behind the scenes to make sure those third-party apps get the required data from one account, like Google.

How OAuth Works

Here’s a basic example of what an OAuth workflow looks like in practice:

1. Request — The user clicks a sign-in button on a web page or application.
2. Access — The client (application) uses third-party authorization credentials, like a Google Account.
3. Sign In — An authorization server creates an authentication server that gets forwarded to the resource server.
4. Connection — Once the token is verified by the resource server, access to the application is granted to the user.

All of this happens in a matter of seconds. It’s a fast and secure way for employees to navigate between business applications without requiring individual login credentials each time someone switches apps.

The simple way to look at OAuth is just two different servers passing information between each other. 

OAuth has an edge over SAML because it’s a bit more advanced in access management capabilities. Here’s a simple analogy to explain the difference.

Let’s say Steve works in a secured building. There’s a guard stationed at the only entrance of the underground parking facility. It’s the guard’s job to verify that only employees enter the lot, and the guard has to verify credentials for each vehicle that arrives before opening the gate. 

When Steve arrives at work, the guard checks his employee ID and also verifies the license plate of his vehicle, comparing it against a list of allowed plates. 

But just because Steve can enter the secure parking garage, it doesn’t mean he can park his car anywhere. There are different lots in the garage for different types of employees. Steve is authorized to park in Lot B Space 119, but he cannot park in the CEO’s designated space—Lot A Space 15.

Entering the garage from a secured gate is an example of authentication based on identity, which can be compared to SAML. But parking the car in a designated space is an example of authorization based on user privileges, which is what OAuth accomplishes.

When to Get SAML Instead

SAML is another approach to single sign-on, but it focuses more on user identification.

That’s why using SAML for enterprise SSO is the most common use case for this technology. 

If your organization needs an SSO solution strictly for traditional web applications, SAML can get the job done. OAuth is more flexible to support different use cases, including mobile apps and smart devices. But SAML technology would be more challenging to use for these modern applications.

SAML is also a good option if you’re only concerned with user authentication. You want to say, “this person is allowed to use this application based on their identity.” But you’re not worried about what permissions and access that user has once they’re in the application. 

You can use SAML for any basic authentication purpose that doesn’t require additional access to specific resources, data, or files within an application or service. 

Let’s say you want to grant a customer or partner access to an internal portal. SAML would be fine. If you’re seeking an employee centralized identity source from an identity provider, SAML would also be fine. 

How SAML Works

Here’s a simple SAML workflow that explains how this technology works behind the scenes:

1. An end-user clicks a sign-in button for a web app.
2. The web application sends a SAML authentication request to IdP (identity provider).
3. The IdP verifies the request and presents a login form if the request is valid.
4. The application redirects the end user’s browser to the IdP to complete authentication. Once they’ve logged in successfully, a SAML token is generated by the IdP, which is sent back to the application.
5. The service provider verifies the SAML assertion, extracts the user’s identity, and then logs them into the service. 

This entire process takes place through just a couple of redirects. 

As previously mentioned, it’s easiest for web applications. SAML isn’t impossible if you’re going from a web app to a native app, but it’s really not ideal. There are definitely some workarounds that allow you to go from web to native, but generally speaking, OAuth is the better solution for this scenario.

When to Use SAML and OAuth Together

There are also scenarios when you can use both of these technologies together. 

Again, SAML and OAuth aren’t mutually exclusive or interchangeable. Since they both have different purposes, they can each be part of your SSO and identity management policy working hand-in-hand.

You can start by using SAML assertion from an IdP. This step involves communication between an authorization server and resource server, which will verify the identity of the user. Once verified, the authorization server can use an OAuth token and provide the user with access to specific resources within a service or application based on that user’s access level.

Depending on your environment, you may need both SAML and OAuth. For example, OAuth handles authorization and SAML takes care of authentication in Microsoft environments. So you could use SAML to grant user access to a system and then OAuth to grant access to protected resources. 

Pricing – Is Product SAML or OAuth the Better Deal?

SAML and OAuth are both open-source technologies. This means that you can create them on your own without paying anything.

But in most cases, you’ll get SAML or OAuth technology when you purchase an SSO solution. Basic SSO solutions can start as low as $2 per user per month. They can range as high as $8 or even $15 per user per month if it’s part of a greater identity as a service (IDaaS) or identity access management (IAM) solution. 

Some solutions are tens of thousands of dollars depending on the complexity of your needs, regardless of the technology you’re using.

For example, Okta is an industry leader in the identity management space. 

Okta has solutions and pricing for workforce SSO starting at just $2 per user per month. This uses SAML technology for access management. Then there’s an API access management add-on for an additional $2 per user per month that’s OAuth 2.0 compliant. 

Universal directory and MFA solutions from Okta start at $3 and $2 per user per month, respectively. 

For customer identity plans using OAuth and SAML for a single application, pricing starts at $14,000 per year.

As you can see, the pricing obviously changes based on the needs of your organization and the use case. Basic SSO capabilities will be more affordable, but it’s unfair to say that one is a “better deal” than the other. 

User Authentication

Winner = SAML

The security assertion markup language (SAML) is designed specifically for user authentication. This technology is made for verifying a user’s identity, then granting them access based on approval or denial of the verification. 

You can think of SAML for user authentication like a house key. By giving someone a key, they have access to the front door and they can enter the house. 

That key does not necessarily grant them access to a locked office door or a locked liquor cabinet. A person with a house key can’t walk into a garage and drive off with one of the cars. You’d need different, more specific keys to do those things.

In an office setting, an employee can use SSO with SAML to log in using their credentials one time when they arrive at work in the morning. For the rest of the day, they’ll have access to the full suite of SAML-based applications. They can switch between apps without any friction or additional login credentials, assuming they’re all web applications. 

User Authorization

Winner = OAuth

OAuth takes SSO and the authentication process one step further. It grants user access privileges within applications and services. These are your specific keys to open locked rooms or drawers within the house. 

Using OAuth, you can determine which users have access to different parts of an application or protected resource. 

For example, let’s say your organization is using software for digital asset management. With OAuth, you can set it up so users in certain departments can only access digital assets related to their job. 

Or maybe you have all of your company’s important files and sensitive information located in a cloud storage solution. Only users with a certain access level should be able to open, read, and download files containing employee social security numbers or trade secrets. Just because a person has the authentication to access your cloud storage system, they shouldn’t be authorized to access every file. 

Identity and Access Management (IAM)

Winner = Tie

SAML and OAuth both play a crucial role in IAM solutions. You can’t have an effective identity and access management policy without using both. 

This is arguably the most common use case for using SAML and OAuth jointly. 

For example, a company employee can log into the organization’s SSO system with a username and password. SAML will verify those credentials, but then OAuth will be used to dictate what that employee can do based on their unique access levels. 

OAuth can pass data between applications granting permissions without exposing any user login data. Everything is handled through authorization tokens. 

Single Sign-On (SSO)

Winner = Tie

SAML and OAuth technology can both be used for single sign-on.

There are different solutions on the market using SAML to facilitate SSO and others that use OAuth. There’s no right or wrong approach here, so I can’t definitively give the edge to either technology in this category.  

Flexibility

Winner = OAuth

SAML works great for organizations that are strictly using web-based applications. It becomes complicated when you’re switching between web apps and native apps.

But OAuth is flexible enough to accommodate both web and native systems.

You can use it to facilitate authentication across web apps, native PC apps, single-page apps, and mobile applications. OAuth is even versatile enough to accommodate other modern technology, like smart TVs.

That’s because OAuth relies on HTTPS instead of message encryption. IT also doesn’t define a specific token format, meaning the tokens can be used cross-platform.