SAML vs OAuth: Compherensive Comparision

Table of Contents

• What is SAML?
• How Does SAML Work?
• What is OAuth?
• How Does OAuth Work
• Similarities Between SAML and OAuth
• Differences Between SAML and OAuth
• When Should You Use SAML or OAuth

In today's interconnected world of digital security, ensuring that users are who they claim to be and managing their access to resources are critical tasks.

Two widely used Identity Access Management (IAM) protocols for these purposes are SAML (Security Assertion Markup Language) and OAuth (Open Authorization).

In this post, you will learn in detail about SAML and OAuth. Additionally, you'll understand how each protocol works, their similarities and differences, and when to use one over the other.

Whether you're managing user authentication for a small application or a large enterprise service, this comparison will provide valuable insights. It will help you make an informed decision.

Finally, you'll be introduced to Permify, an open source Authorization as a Service (AaaS) solution.

Let's start by understanding what SAML is and how it functions in the realm of authentication and authorization.

What is SAML?

SAML is an open standard for exchanging authentication and authorization data between parties, specifically between an identity provider (idP) and a service provider (SP).

Developed by the OASIS Security Services Technical Committee, SAML enables single sign-on (SSO). In practice, allowing users to authenticate once and gain access to multiple applications without needing to log in separately to each one.

For example, suppose you work for a company that uses several cloud-based applications, such as an email service, a project management tool, and a customer relationship management (CRM) system. With SAML, you only need to log in once through the company's identity provider. After authentication, you can access all these applications without needing to log in again for each one.

How Does SAML Work?

SAML operates through a series of exchanges between three main entities: the user (or principal), the identity provider (IdP), and the service provider (SP). The process involves the creation, transmission, and verification of security assertions.

Here's a step-by-step breakdown on how SAML works in practice:

1. User Request Access: A user attempts to access a service provider (SP) application, such as a company's project management tool or email service.

2. Redirects to Identity Provider: The SP detects that user is not authenticated and redirects the user to the identity provider(IdP). This redirection is done through a SAML Authentication request message.

3. User Authenticates with IdP: The user is prompted to log in by the identity provider. The user enters their credentials (username and password).

4. Generation of SAML assertion: Once the user is authenticated, the IdP creates a SAML assertion. This assertion is an XML document that includes information about the user and the authentication event.

5. Assertion Sent to SP: The SAML assertion is sent back to the service provider, either directly or via the user's browser.

6. SP Validates the Assertion: The SP receives the SAML assertion and validates it. In practice, this involves checking the signature of the assertion to ensure it was issued by a trusted IdP and has not been tampered with.

7. User Access Granted: Once the assertion is validated, the SP grants the user access to the requested application or resource.

Description: Visual overview of how SAML works

Example Scenario

To explain how SAML works better, consider an employee, Durojaye, who want to access his company's CRM system. Here's how SAML would facilitate this:

1. Access Request: Durojaye goes to the CRM's login page

2. Redirection to IdP: The CRM system (SP) redirects Durojaye to the company’s identity provider (IdP).

3. Authentication: Durojaye logs in with his corporate credentials on the IdP’s login page.

4. Assertion Creation: The IdP verifies Durojaye’s credentials and creates a SAML assertion indicating that Durojaye has been authenticated.

5. Assertion Transmission: The IdP sends the SAML assertion to the CRM system, typically via Durojaye’s browser.

6. Validation: The CRM system validates the assertion’s authenticity.

7. Access Granted: Durojaye is granted access to the CRM system without needing to log in again.

Now that we've covered SAML, let's move on to understanding OAuth.

What is OAuth?

OAuth is an open, token-based authorization standard for access delegation. It's commonly used to grant websites or applications limited access to user information without exposing passwords.

OAuth allows third-party services to exchange information on behalf of the user. In practice, providing a secure and efficient way to handle authorization in modern web applications.

Developed by the Internet Engineering Task Force (IETF), OAuth facilitates scenarios where users can authorize one application to interact with another on their behalf without sharing credentials. This is particularly useful for scenarios like allowing a third-party app to post on a user's social media timeline or enabling a website to access a user's profile information from another service.

OAuth involves several key components:

1. Resource Owner (User): The user who owns the data and grants permission to access it.

2. Client: The application requesting access to the resource owner's data.

3. Resource Server: The server that holds the protected resources and accepts access tokens to grant access.

4. Authorization Server: The server that authenticates the resource owner and issues access tokens to the client.

Consider a scenario where a you want to allow a photo-editing application to access your photos stored on a cloud service without sharing your login credentials for the cloud service. OAuth enables this secure interaction.

How Does OAuth Work?

OAuth operates through a series of steps involving the resource owner, the client, the resource server, and the authorization server.

Here’s a step-by-step breakdown of how OAuth works in practice:

1. User Initiates Request: The user opens the photo-editing app and wants to access their cloud-stored photos.

2. Client Request Authorization: The photo-editing app (client) redirects the user to the cloud service's authorization server, requesting access to the user's photos.

3. User Grant Permission: The user is prompted to login to the cloud service (if not already logged in) and grant permission for the photo-editing app to access their photos.

4. Authorization Server Issues Authorization Code: Once the user grants permission, the authorization server redirects the user back to the photo-editing app with an authorization code.

5. Client Requests Access Token: The photo-editing app sends the authorization code to the authorization server, along with its client credentials, to request an access token.

6. Authorization Server Issues Access Token: The authorization server verifies the authorization code and client credentials, then issues an access token to the photo-editing app.

7. Client Accesses Resource Server: The photo-editing app uses the access token to make API requests to the cloud service’s resource server to access the user's photos.

8. Resource Server Validates Token: The resource server validates the access token and grants the photo-editing app access to the user’s photos.

Description: Overview of how OAuth works

Example Scenario

To better understand OAuth, consider a user called Olusegun who wants to use a third-party budgeting app to access his bank account transactions:

1. User Initiates Request: Olusegun opens the budgeting app and selects the option to connect his bank account

2. Client Requests Authorization: The budgeting app redirects Olusegun to his bank’s authorization server to request access to his transaction data.

3. User Grants Permission: Olusegun logs into his bank account and authorizes the budgeting app to access his transaction data.

4. Authorization Server Issues Authorization Code: After granting permission, the bank’s authorization server redirects Olusegun back to the budgeting app with an authorization code.

5. Client Requests Access Token: The budgeting app sends the authorization code to the bank’s authorization server to request an access token.

6. Authorization Server Issues Access Token: The bank’s authorization server verifies the authorization code and client credentials, then issues an access token to the budgeting app.

7. Client Accesses Resource Server: The budgeting app uses the access token to retrieve Olusegun’s transaction data from the bank’s resource server.

8. Resource Server Validates Token: The bank’s resource server validates the access token and grants the budgeting app access to Olusegun’s transaction data.

This flow ensures that Olusegun’s banking credentials are not shared with the budgeting app. In practice, this maintains security and privacy while allowing seamless integration between services.

Now that we've covered OAuth, let's move on to comparing SAML and OAuth in terms of their similarities and differences.

Similarities Between SAML and OAuth

While SAML and OAuth are distinct protocols designed for different purposes within IAM, they share several similarities. Both are critical in ensuring secure access to web applications and services. In addition, they contribute to the overarching goal of managing identities and authorizations effectively.

Here are some key similarities between SAML and OAuth:

1. Security Protocols: Both SAML and OAuth are security protocols designed to facilitate secure authentication and authorization in digital environments. They ensure that users and applications can access resources safely without exposing sensitive information.

2. Single Sign-On (SSO): SAML and OAuth both enable Single Sign-On (SSO) capabilities, allowing users to authenticate once and gain access to multiple services without needing to log in repeatedly. This enhances user convenience and streamlines access to various applications.

3. Token-Based: In SAML, the token is an XML-based SAML assertion, whereas, in OAuth, the token is typically a JSON Web Token (JWT) or a similar format. These tokens carry information about the user's authentication status and permissions.

Differences Between SAML and OAuth

Here are key differences between SAML and OAuth:

When Should You Use SAML or OAuth

Choosing between SAML and OAuth depends on the specific requirements of your application and the nature of the interactions you need to facilitate.

Here's a guide to help you decide when to use each protocol:

Use SAML When:

1. Internal Applications: SAML is well-suited for scenarios where you need to enable single sign-on (SSO) and federated identity management within an organization. If you have multiple web applications or services within your enterprise ecosystem and want to streamline authentication for users, SAML is a robust choice.

2. Centralized Identity Provider: If you have a centralized IdP that manages user authentication across your organization, SAML provides a standardized way to authenticate users. It also facilitates the propagation of identity information to service providers (SPs).

3. Enterprise Environments: SAML is ideal for enterprise environments where security, compliance, and centralized control over user access are paramount. It offers strong authentication mechanisms and supports the exchange of rich identity information between systems.

Use OAuth When:

1. Third-Party Integration: OAuth is the preferred choice when you need to enable secure access to your application or API by third-party services or applications. It allows users to grant permissions to external applications without sharing their credentials. In practice, this makes it suitable for scenarios involving integrations with social media platforms, cloud services, or other external APIs.

2. Mobile and Web Applications: OAuth is well-suited for modern mobile and web applications that need to access resources on behalf of users. Its token-based authentication model and support for refresh tokens make it efficient for handling authentication and authorization in distributed environments.

3. Consumer-Facing Applications: If you're developing a consumer-facing application or service that requires delegated access to user data, OAuth provides a flexible and user-centric approach to authorization. It allows you to grant specific permissions (scopes) to third-party applications, giving you fine-grained control over your data.

Looking to Implement Authorization ?

While SAML and OAuth handle authentication and some aspects of authorization, Permify is specifically designed to manage authorization, providing more flexibility and fine-grained control over permissions.

Incorporating Permify into your IAM strategy empowers you to harness the benefits of SAML and OAuth without the burden of managing complex access control infrastructure.

If you want to build robust authorization based systems, we can help. Check out our open source repository or join our Discord community to learn more!