SAML vs OAuth: A side-by-side comparison 

Choosing the right security framework is key to keeping user identity under lock and key. IT admins have a few options to choose from, but the two big hitters are Security Assertion Markup Language Single Sign-On (SAML SSO) and Open Authorization (OAuth).

Both play key roles in managing identity and access. While they might seem similar at a glance, they each have their own unique purposes. Let’s take a closer look.

What’s the difference between SAML and OAuth?

First, let’s take a look at what they do. 

SAML in a nutshell

SAML SSO is designed for both authentication AND authorization. It authenticates users by verifying their identity, and then authorizes them to access various services or resources. 

It operates through the exchange of XML-based assertions between the identity provider and the service provider. Essentially, SAML not only confirms who you are but also defines what services and resources you have permission to access. 

Think of it as being like a passport that not only proves your identity but also contains visas specifying which countries you’re allowed to enter. A one-stop shop for access, if you will. 

OAuth in a nutshell

OAuth, on the other hand, is primarily built for authorization. It focuses on granting third-party services limited access to a user’s resources without exposing the user’s credentials. 

OAuth uses access tokens, which are credentials used to access protected resources but do not reveal the user’s identity. These tokens are obtained through various flows, tailored to different scenarios — for instance, a web app might use a different flow compared to a mobile app. 

While OAuth itself doesn’t authenticate users, it’s commonly used alongside protocols like OpenID Connect, which adds an authentication layer on top of OAuth’s authorization framework.

SAML and OAuth: a side-by-side comparison 

Comparison point	SAML	OAuth
Primary use	Authentication and authorization	Primarily for authorization
Tokens	SAML Assertion (XML document containing user’s identity and access rights)	Access tokens (credential used for accessing API)
Enterprise security	Widely adopted for enterprise security, suitable for secure, cross-domain SSO	Common in both consumer and enterprise, scalable and flexible for various access
Operation	Operates by exchanging assertions between identity and service providers	Provides multiple flows for different types of applications, streamlined for modern usage
Complexity and flexibility	More complex, uses XML, highly flexible for varied needs	Simpler, uses JSON, versatile and suitable for modern apps
Complementary nature	Can provide both authentication and authorization, more suited for enterprise scenarios	Often used with OpenID Connect for authentication alongside OAuth’s authorization

How does OAuth work?

OAuth tokens, by themselves, are not encrypted. They are typically bearer tokens, meaning that whoever possesses the token can access the resources it grants. Because of this, the security of an OAuth implementation heavily relies on the secure transmission of these tokens. This is generally done via the use of HTTPS, utilizing SSL/TLS protocols to encrypt the data transmitted between the client, the authorization server, and the resource server.

While this method is effective and typically secure, OAuth tokens are only as strong as the implementation of the SSL/TLS protocols and the diligence in handling these tokens. 

A step-by-step guide to the OAuth operating procedure 

1. Requesting permission

The process begins when you, the user, try to access a resource or service (like an app) that needs information from another service you use (like a social media platform). The application will request your permission to access this data.

2. Application registers

Before this, the application will have registered with the service it wants to access, obtaining credentials (like a client ID and secret) used to identify itself.

3. Authorization grant

If you grant permission, the service you’re using (like the social media platform) will issue an authorization grant. This grant is a credential representing your consent for the application to access your data.

4. Access token request

The application then exchanges this authorization grant for an access token by making a request to the service’s token endpoint. This request includes its credentials and the authorization grant.

5. Issuing access token

If the application’s credentials and the authorization grant are all valid, the service issues an access token (and possibly a refresh token). This access token is a special code that the application can use to access your information.

6. Making API calls

The application uses the access token to make API calls on your behalf. It includes the token in the API requests it sends to the service. The service then validates the token and, if it’s valid, returns the requested data.

7. Token expiry and refresh

Access tokens are usually short-lived for security reasons. If the application still needs access after the token expires, it can use a refresh token (if provided) to obtain a new access token without requiring a new authorization grant from you.

OAuth supports various types of authorization grants for different scenarios:

• Authorization code: Used by web and mobile apps, where the code is obtained by using an authorization server as an intermediary between the client and resource owner.
• Implicit: Less secure, used by web apps running in a browser, where the token is obtained directly.
• Password: Used when the application has the user’s username and password.
• Client credentials: Used when the application acts on its own behalf, not on behalf of a user.

How does SAML work?

With SAML, you can log in to multiple websites (service providers) using one set of credentials shared from a centralized identity provider. This is especially useful in business environments where users need to access a suite of interrelated applications. Here’s a general breakdown of how SAML operates.

A step-by-step guide to the SAML operating procedure 

1. User access initiation:

The process starts when you attempt to access a service or application (the service provider). If you’re not already authenticated, the service provider needs to know who you are.

2. Redirect to identity provider:

The service provider redirects you to the identity provider. The identity provider is responsible for verifying your identity. It might prompt you to log in unless you’ve already done so.

3. Authentication by the identity provider:

The identity provider asks you to log in (unless you already are). You’ll enter your credentials (like a username and password).

4. Generation of SAML assertion

Once your identity is confirmed, the identity provider generates a SAML assertion. A SAML assertion is an XML document that acts as evidence of your identity and possibly your permissions (authorization). It might include information like who you are, your email, and which groups you belong to.

5. SAML assertion is sent back to the service provider:

The SAML assertion is then sent back to the service provider, usually through your browser.

6. Service provider processes the SAML assertion:

The service provider processes the SAML assertion, extracts the necessary information, and logs you in.

7. User access granted

Now that the service provider knows who you are and has confirmed this via the identity provider, you’re granted access to the service or application.

What are the benefits of SSO?

SAML Single Sign-On, or SSO, is like having a master key that opens multiple doors. Instead of carrying around a heavy keychain with different keys for each door, you just carry one that gets you into everywhere you need to go. In the digital world, these ‘doors’ are your various applications and services, and SSO is a way to access them all with just one set of credentials. Here are some of the key benefits:

Convenience for users

With SSO, users don’t have to remember multiple passwords. They log in once and get access to all the applications and services they need. This convenience can lead to a better overall user experience.

Increased productivity

Less time spent entering or resetting passwords means more time for actual work. Users can quickly transition between services without the interruption of a login prompt, which can significantly streamline workflow.

Enhanced security

It might seem counterintuitive, but having one set of credentials can actually be more secure than having many. SSO solutions typically involve robust authentication mechanisms. Plus, users are less likely to resort to unsafe practices like using simple, easily remembered passwords or writing them down.

Reduced IT costs

Fewer password-related help desk calls means less time and money spent on support. Password issues are among the most common reasons people contact IT support, so reducing these can lead to significant savings.

Simplified management and compliance

For administrators, managing user access across multiple applications becomes much more straightforward with SSO. It’s easier to track who has access to what, which is not just a convenience but also a regulatory requirement in many industries.

Lowered risk of phishing attacks

When users are only logging in through a single, secure point of entry, the potential for successful phishing attacks can be reduced. Users become accustomed to one login procedure and are less likely to fall for fake login prompts.

Easier onboarding and offboarding

When a new employee joins the company or when someone leaves, administrators only need to add or revoke access in one place. This not only saves time but also helps ensure no access is accidentally left active when it shouldn’t be.

When to use SAML and when to use OAuth

Choosing between SAML and OAuth/OIDC isn’t just about knowing what does what. It’s also about understanding when each one shines brightest. Here are a few considerations to keep in mind:

• Think about the user experience: How seamless does the login process need to be? How many different services are users interacting with?

• Consider your security requirements: What level of security do you need? Are there industry standards or regulations you need to comply with?

• Evaluate your technical environment: Are you working with a lot of legacy systems, or are you building something new? What do the systems you’re interfacing with support?

• Know your needs: Start by asking the right questions. What exactly are you trying to achieve? Are you looking for a way to authenticate users, authorize them, or both? Are your users accessing multiple internal applications, or do they need to interact with external services?

• Plan ahead: Think about not just your immediate needs but also what you might need down the line. Are you likely to integrate with more services or applications in the future? 

• Choose both: Sometimes, it’s not an either/or situation. In some complex scenarios, using a combination of SAML for authentication and OAuth/OIDC for authorization is your best bet.

Use SAML if you:

• Need Single Sign-On (SSO) for enterprise applications: If your organization uses a lot of different applications and you want users to seamlessly access them with one set of credentials, SAML is a strong choice. It’s particularly useful in large organizations with many internal systems.

• Are focussed on authentication: When the main concern is verifying the identity of users across various domains and services, SAML’s strong suit in authentication makes it the go-to option.

• Are dealing with enterprise-level security requirements: SAML’s strong security features are a good match for organizations with stringent security requirements. It’s been around for a while and is a trusted standard in many industries.

• Are integrating with legacy systems: Many older systems are built to support SAML. If you’re working in an environment with a lot of legacy systems, SAML might be more compatible.

• Are a government application: When dealing with government data, which often includes highly confidential information, the robust security features of SAML make it an ideal choice. Its ability to encrypt assertions and offer secure, cross-domain SSO aligns well with the stringent security requirements typical in government settings.

• Are implementing Virtual desktop infrastructure (VDI): In scenarios where many employees are accessing a centralized set of resources, such as in a VDI setup, SAML’s strong SSO capabilities and enterprise focus offer a seamless and secure user experience.

Use OAuth if you:

• Need to authorize third-party access without exposing user credentials: If you’re building or using an application that needs to access user data from another service (like a user’s calendar or contacts list), OAuth lets you do this securely without handing out the user’s password.

• Are developing mobile and web applications: OAuth is particularly well-suited for modern applications, including mobile and single-page web apps. It’s the standard of choice for most new applications, especially when they need to interact with services from multiple providers.

• Want a simpler, more flexible solution: OAuth is generally easier to work with than SAML and offers more flexibility in many scenarios, especially when you’re dealing with various types of devices and access patterns.

• Are considering future compatibility: OAuth is widely adopted by many internet giants for user authentication and authorization. If you anticipate integrating with a variety of external services, OAuth might give you an easier path forward.

• Have a mobile or consumer application: OAuth, particularly when paired with OIDC, performs well with mobile and consumer applications. Its flexibility, ease of implementation, and ability to provide a smooth user experience without compromising security make it suitable for applications where user sessions tend to be shorter and more varied.

• Need to grant temporary access to resources: If you need to grant temporary access to certain resources, OAuth’s lightweight nature and ability to issue short-lived tokens make it a practical choice. It allows for precise control over what each token grants access to without the overhead of more complex protocols.

If you’re ever feeling stuck, a chat with a security expert can help clear things up and guide you towards the best path forward. They can help you navigate these decisions so that you end up with a secure, efficient, and user-friendly solution.

Introducing Nulab Pass

Say goodbye to password fatigue and hello to centralized, streamlined security. Nulab Pass is a SAML SSO subscription that gives you enterprise-grade protection for all of your Nulab apps, including Backlog and Cacoo. Managers can enjoy peace of mind, while users only need to enter their credentials once to enjoy full, secure access. Give it a try today!