Table of contents

Table of Contents

1. Introduction
2. What is Authentication and Authorization
3. What is SAML
4. What is OAuth 2.0
5. What are the differences between SAML and OAuth 2.0
6. What is OpenID Connect (OIDC) and how does it fit in?
7. Conclusion

Introduction

Ensuring that your application is secure has become a fundamental requirement in today’s digital landscape. OAuth2.0 and SAML both serve the same fundamental purpose of enabling secure, seamless access to applications. In this article, we will delve into the core concepts of authentication and authorization and provide a detailed comparison of OAuth2.0 and SAML.

What is Authentication and Authorization

Authentication and authorization are often used interchangeably even though they don’t mean the same thing. Authentication is the process of identifying who the user is. For example, consider a club that is member-only. Authentication would involve identifying who the member is before they are allowed to enter the club. Traditional email+password login, passwordless login, and social login are all ways of implementing authentication for your app.

Authorization, on the other hand, involves identifying what actions the user is allowed to perform. Sticking with the same example of the club, authorization would involve checking the membership of the visitor to see if they are allowed in specific parts of the club. Role-Based Access Control (RBAC), Access Control Lists (ACLs), etc., are common ways of implementing authorization in your app.

SAML is primarily used on an enterprise level for logging in users and employees and is hence a mechanism for adding authentication to your system. OAuth 2.0 is a protocol that allows websites to provide users access to third-party services. Even though this may involve using an identity server to identify the user, the main function of the protocol is to provide access to a user and is hence a mechanism for authorization.

What is SAML

Security Assertion Markup Language (SAML) is an open protocol that allows exchanging a user’s identity information between two parties, typically an Identity Provider and a Service Provider. It allows for Single Sign-On (SSO) because it lets users access multiple applications after logging in with the Identity Provider once.

How does SAML work?

SAML facilitates communication between the identity provider and the service provider through a series of XML-based messages. Read our blog on SAML for a more in-depth understanding of how it works. This process involves:

• Service Provider (SP): The service or application that the user is trying to access
• Identity Provider (IdP): The provider that the user has logged in to, this provider implements appropriate authentication mechanisms and communicates with the service provider using SAML assertions.
• SAML Assertions: Assertions are XML-based messages between the IdP and the SP containing information about whether the user is logged in, any relevant information about the user, and what resources they are authorized to access. Assertions are of the following types:
  • Authentication Assertions: Confirm the user’s identity and authentication method.
  • Attribute Assertions: Convey additional information about the user, such as email address, roles, or group memberships.

SAML Authentication Flow

The typical SAML authentication flow involves the following steps:

1. User Request: The user attempts to access a resource on the service provider’s site.
2. Authentication Request: The service provider redirects the user to the identity provider for authentication.
3. User Authentication: The identity provider authenticates the user using methods such as username/password, multi-factor authentication, or biometrics.
4. SAML Assertion: Upon successful authentication, the identity provider generates a SAML assertion and sends it back to the service provider.
5. Assertion Validation: The service provider validates the SAML assertion to ensure it is legitimate and has not been tampered with.
6. Access Granted: Once validated, the service provider grants the user access to the requested resource.

Common use cases for SAML

SAML is well-suited for the following use cases:

• Enterprise SSO: Organizations need to provide employees with seamless access to various internal and external applications using a single set of credentials.
• Federated Identity: Multiple organizations collaborate and require a trusted way to share user identities and permissions across domains.
• Cloud Services: Enterprises leverage cloud-based applications and want to integrate them with their existing identity management systems for unified access control.

Why should you use SAML

• Single Sign-On (SSO): SAML enables SSO, allowing users to access multiple applications with a single set of credentials.
• Enhanced Security: By centralizing authentication with a trusted identity provider, SAML reduces the risk of password theft and phishing attacks.
• Interoperability: SAML is an open standard, which means it is widely supported across different platforms and vendors. This interoperability allows organizations to integrate diverse applications and services seamlessly.
• Scalability: SAML’s centralized authentication mechanism simplifies user management and scalability, making it easier to provision and de-provision user access across multiple applications.

What is OAuth 2.0

OAuth 2.0 is an open standard for token-based authentication and authorization. It allows websites to provide access to users without having to share passwords or require users to enter their passwords again.

How does OAuth 2.0 work?

OAuth 2.0 flows typically involve the following components:

• Resource Owner: The system that owns the data and grants access to a third-party application.
• Client Application: The application requesting access to the user’s data. It does not handle the user’s credentials directly.
• Authorization Server: The server that authenticates the user and issues access tokens to the client application. It typically includes an identity provider like Google, Facebook, or a custom enterprise server.
• Resource Server: The server that hosts the protected resources and accepts access tokens to grant access to the data.

OAuth 2.0 authorization flow

The authorization flow involves the following steps:

1. User Request: The user initiates the process by attempting to access a resource through the client application.
2. Authorization Redirect: The client application redirects the user to the authorization server, requesting access to specific resources.
3. User Authentication and Consent: The authorization server authenticates the user (typically through login) and prompts them to consent to the access request. The user grants permission, authorizing the client application.
4. Authorization Code: Upon successful authentication and consent, the authorization server redirects the user back to the client application with an authorization code. For example, when using Google login, the authorization code is sent back to the client application as a query parameter.
5. Access Token Request: The client application exchanges the authorization code for an access token by making a request to the authorization server.
6. API Request: The client application uses the access token to make API requests to the resource server and access the protected resources on behalf of the user.

Common use cases for OAuth 2.0

OAuth 2.0 is well-suited for the following use cases:

• Third-Party Integrations: Applications need to access user data from other services, like social media platforms, without exposing user credentials.
• Mobile and Web Applications: Apps require a secure and seamless way to authenticate users and access APIs.
• API Security: Protecting APIs by ensuring that only authorized applications and users can access them.

Why should you use OAuth 2.0

• Security: OAuth 2.0 enhances security by allowing users to grant limited access to their resources without sharing credentials. Access tokens have limited lifespans and scopes, reducing the risk of misuse.
• User Experience: OAuth 2.0 streamlines user experience by enabling single sign-on (SSO) capabilities, allowing users to access multiple services without repeatedly logging in.
• Scalability and Flexibility: OAuth 2.0 supports various grant types and flows, making it adaptable to a wide range of applications.
• Interoperability: As an open standard, OAuth 2.0 is widely adopted and supported across numerous platforms and services, promoting interoperability between different systems.

What are the differences between SAML and OAuth 2.0

• Purpose: SAML is used to implement authentication which helps identify the user. OAuth 2.0 is used for authorization which helps identify what the user can and cannot access.
• Use case: SAML is typically used on an enterprise level and is not well-suited for large end-user-facing applications. OAuth 2.0 is an open protocol widely used by both enterprise and end-user-facing applications.
• Communication: SAML involves the use of XML-based messages that provide information about the user’s identity. OAuth 2.0 uses REST APIs and access tokens in the form of JWTs to transmit user authorization information.
• Complexity: OAuth 2.0 is generally considered to be more straightforward in terms of implementation.
• Cost: SAML often requires the identity server to have more complex parsing capabilities because of messages being in XML, this adds to development and maintenance costs. SAML also requires certain expertise from developers which can be hard and expensive to hire for.

What is OpenID Connect (OIDC) and how does it fit in?

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 protocol. While OAuth 2.0 is designed primarily for authorization, allowing third-party applications to access user resources, OIDC extends this functionality to include authentication. This means that using OIDC in your application eliminates the need for SAML.

This means that using OIDC in your application eliminates the need for SAML. That being said, the availability of SAML as a feature is often seen as a sign of product readiness by large enterprises.

How OIDC works

OIDC operates by leveraging OAuth 2.0’s authorization flows and adding an identity layer to handle user authentication. The OIDC flow involves the following steps:

1. Authentication Request: The client application (RP) directs the user to the OpenID Provider (OP) for authentication.
2. User Authentication: The OP authenticates the user using methods such as username/password, multi-factor authentication, or biometrics.
3. Authorization Code: Upon successful authentication, the OP redirects the user back to the client application with an authorization code.
4. Token Exchange: The client application exchanges the authorization code for an identity token and an access token by making a secure request to the OP.
5. Identity Token Validation: The client application validates the identity token to confirm the user’s identity.
6. User Information Access: The client application uses the access token to request additional user information from the OP’s userinfo endpoint.

OIDC vs OAuth 2.0

• Authentication: OIDC provides an identity layer on top of OAuth 2.0, enabling user authentication in addition to authorization. OAuth 2.0 alone is primarily for authorization.
• User Information: OIDC allows client applications to retrieve authenticated user information through identity tokens and the userinfo endpoint, which OAuth 2.0 does not provide natively.

Read our blog, OIDC vs OAuth, for a more detailed explanation of the differences between the two protocols.

OIDC vs SAML

• Simplicity: OIDC uses JSON and RESTful web services, making it simpler to implement and integrate compared to the XML-based SAML protocol.
• Mobile and Web-Friendly: OIDC is designed to be more web and mobile-friendly, fitting well with modern application architectures, while SAML is more suited for enterprise environments and single sign-on scenarios.

Use cases for OpenID Connect (OIDC)

• Web and Mobile Applications: OIDC is ideal for web and mobile applications that require secure user authentication and access to user profile information.
• Single Sign-On (SSO): Organizations can use OIDC to enable SSO across multiple applications, improving user convenience and security.
• API Security: OIDC can secure API endpoints by verifying the identity of users and client applications accessing the APIs.

---

SAML, OAuth 2.0, and OIDC are all powerful tools when building authentication and authorization for your application, and each protocol has its own advantages and disadvantages. By understanding the differences between them, developers can make well-informed decisions about what they should use when building their applications.