Before diving into the differences between SAML (Security Assertion Markup Language) and OAuth 2.0, let's first discuss what they have in common. Both are protocols used for authentication and authorization. While these terms are sometimes mistakenly used interchangeably, they serve distinct purposes. Authentication asks, “Who are you?”, whereas authorization asks, “What are you allowed to do?”. 

This means that SAML and OAuth 2.0 are used for very distinctive purposes and work on different mechanisms. The good news is that Drupal integrates really well with both these protocols. In this article, we’ll talk about how different the protocols are from each other and also how to implement them in your Drupal 10 website.

What is SAML

SAML is an XML-based authentication system that works across different domains. It lets you do Single Sign-On (SSO), so you can access multiple applications with just one set of credentials.

Key components of SAML

1. Assertions

Assertions are the heart of SAML transactions. They contain information about a user, such as their identity, attributes, and authentication status. SAML defines three types of assertions: Authentication, Attribute, and Authorization Decision.

2. Identity Provider (IdP)

The IdP is responsible for authenticating users and generating SAML assertions. It acts as a trusted entity that asserts the identity of users to service providers.

3. Service Provider (SP)

It is the application or service a user is trying to access. The SP consumes SAML assertions and makes access control decisions based on the information provided by the IdP.

4. Single Sign-On (SSO):

SAML enables SSO, allowing users to authenticate once with the IdP and access multiple SPs without re-entering credentials.

The SAML Workflow

  1. User Access Request
    A user attempts to access a service or application (SP).
  2. SP Initiated SSO
    The Service Provider (SP) creates an SAML authentication request, initiating the process by redirecting the user to the Identity Provider (IdP).
  3. IdP Authentication
    The IdP authenticates the user.
  4. SAML Assertion Generation
    Upon successful authentication, the IdP generates a SAML assertion containing user information.
  5. Assertion Delivery to SP
    The IdP sends the SAML assertion to the user's browser, which then delivers it to the SP.
  6. SP Validation
    The SP validates the SAML assertion, and if successful, grants the user access.

Image source:

Implementing SAML in Drupal 10

  • Ensure that you have Drupal 10 installed and configured.
  • Ensure that Composer is installed on your local system before proceeding.
  • Install the miniorange_saml Authentication Module:
composer require 'drupal/miniorange_saml:^3.0'
  • Enable the module:
drush en miniorange_saml
  • Configure your SP’s by following the steps mentioned in the “” file of module.

Checkout the official documentation of SSO using Google Apps as Identity Provider (IDP).
Note: We can also configure SAML to work as an IdP for others which they can use to get sign into other’s platform using our IdP platform (Drupal). For more information please checkout the official documentation here.

What is OAuth2

OAuth 2.0 authentication is a method of granting users access to a protected resource, such as a website or application, without sharing their username and password. Instead, the user grants permission to a third-party application, which then accesses the protected resource on their behalf. 

This provides an extra layer of security and allows for more control over the user's data.
OAuth2 is commonly used for social media, email, and other online services. The thing to note here is that OAuth2 is an authorization mechanism, not an authentication mechanism.

Key Components of OAuth2

1. Resource Owner (User)

The Resource Owner is an entity (typically a user) that owns the protected resources. These resources could include data, images, or any other type of information.

2. Client

The Client, representing the application or service, initiates requests for access to protected resources on behalf of the Resource Owner. It may take the form of a web application, mobile app, or any other software application.

3. Authorization Server

This is responsible for authenticating the Resource Owner(User), obtaining their consent, and issuing access tokens. It plays a pivotal role in the OAuth2 workflow, ensuring secure authorization processes.

4. Resource Server

The Resource Server is the host for the protected resources that the Client intends to access. It verifies the validity of access tokens provided by the Client and provides the requested resources if the token is deemed valid.

5. Access Token

The Access Token is a credential representing the authorization granted to the Client. It is a string that the Client includes in its requests to the Resource Server to access the protected resources.

6. Authorization Grant

An Authorization Grant is a credential representing the Resource Owner's authorization for the Client to access their protected resources. There are various types of authorization grants, including authorization codes, implicit grants, client credentials, and resource owner passwords.

7. Redirection URI

During the OAuth2 flow, the Client specifies a Redirection URI where the Authorization Server sends the user after authentication and consent. This URI is used to deliver the authorization code or access token back to the Client.

8. Scope

The Scope parameter defines the range of the access that the Client is requesting. It specifies the permissions the Client is seeking from the Resource Owner. Scopes can be predefined or defined by the application.

9. Token Endpoint

The Token Endpoint is an endpoint on the Authorization Server used by the Client to exchange the Authorization Grant for an Access Token. It plays a crucial role in the OAuth2 Token Exchange process.

10. Refresh Token

The Refresh Token is an optional credential that can be used by the Client to obtain a new Access Token without requiring the Resource Owner to reauthenticate. It provides a way to extend the validity of the access.

The OAuth2 Workflow

  1. The client initiates the authentication process by redirecting the user to the authorization server.
  2. The user authenticates with the authorization server and grants permissions to the client.
  3. The authorization server grants an access token to the client.
  4. The client presents the access token to the resource server to access protected resources on behalf of the user.

Image Source: Oracle

Implementing OAuth 2.0 in Drupal

Let’s take an example of logging into a Drupal site using Google credentials:

1. Install and Enable the OAuth2 Authentication Module

  1. Download and install the OAuth2 Authentication respective module from the website or using Composer.
  2. Enable the module in the Drupal administration interface.

2. Configure OAuth2 Providers

  1. Navigate to the Configuration page and select OAuth2 Authentication settings.
  2. Add a new OAuth2 provider configuration by providing details such as client ID, client secret, authorization endpoint, token endpoint, and scope and save configuration.

For detailed information please refer to module’s file.

3. Test Authentication Integration

  1. Once the OAuth2 provider is configured, Drupal will handle the authentication flow automatically.
  2. Test the integration by logging out of Drupal and attempting to log in using the OAuth2 provider credentials.
  3. Verify that the authentication process is successful and that user accounts are created or linked appropriately.

4. Secure Access and Manage Permissions

  1. Ensure that access tokens are securely stored and transmitted to prevent unauthorized access.
  2. Manage permissions and access control settings within Drupal to restrict access to sensitive resources based on user roles and permissions.

Key differences between SAML and OAuth2




Purpose Identify and Single Sign-On (SSO) Authorization and Access Control
Use Case Authentication or Cross-domain authentication Authorization or Third-party application authorization
Protocol Type Authentication protocol Authorization framework
Authentication Flow Browser Redirect (POST or Artifact Binding) Redirect or Direct Communication
Token Type Assertions (SAML Tokens, typically XML) Access Tokens like: JWT, Bearer Tokens, etc (typically JSON)
Token Validations Signature verifications Token validation against Authorization Server
Scenarios Often used for enterprise SSO Commonly used in API access and third-party integrations
Use with APIs Less common for APIs authrorization Widely used for securing APIs’ and accessing resources
Supported by Drupal Yes, via modules such as SimpleSAMLphp Yes, via modules like Social OAuth authentications
Integration Complexity More complex due to SSO and identity mapping Generally simpler for basic use cases
Use in Mobile Apps Possible, but less common Commonly used for mobile app authentication
User Experience Seamless SSO experience for users Transparent authorization for users
Examples in Drupal Modules SimpleSAMLphp, Shibboleth OAuth2 Authentication, OAuth2 Server

Final Thoughts

It's important to note that SAML and OAuth2 serve different purposes, and in some scenarios, they can be used together. For instance, SAML could handle authentication, and OAuth2 could handle authorization in a federated identity scenario. The choice between SAML and OAuth2 often depends on the specific requirements of the application and the use case. Drupal 10 provides modules for both SAML and OAuth2 to accommodate various authentication and authorization needs. Talk to our Drupal experts to find out how we, as a leading Drupal development company, can help build secure, robust, and user-friendly digital solutions with Drupal.

Contact us