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
User Access RequestA user attempts to access a service or application (SP).
SP Initiated SSOThe Service Provider (SP) creates an SAML authentication request, initiating the process by redirecting the user to the Identity Provider (IdP).
IdP AuthenticationThe IdP authenticates the user.
SAML Assertion GenerationUpon successful authentication, the IdP generates a SAML assertion containing user information.
Assertion Delivery to SPThe IdP sends the SAML assertion to the user's browser, which then delivers it to the SP.
SP ValidationThe SP validates the SAML assertion, and if successful, grants the user access.
Image source: Drupal.org
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 “Readme.md” 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
The client initiates the authentication process by redirecting the user to the authorization server.
The user authenticates with the authorization server and grants permissions to the client.
The authorization server grants an access token to the client.
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
Download and install the OAuth2 Authentication respective module from the Drupal.org website or using Composer.
Enable the module in the Drupal administration interface.
2. Configure OAuth2 Providers
Navigate to the Configuration page and select OAuth2 Authentication settings.
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 README.md file.
3. Test Authentication Integration
Once the OAuth2 provider is configured, Drupal will handle the authentication flow automatically.
Test the integration by logging out of Drupal and attempting to log in using the OAuth2 provider credentials.
Verify that the authentication process is successful and that user accounts are created or linked appropriately.
4. Secure Access and Manage Permissions
Ensure that access tokens are securely stored and transmitted to prevent unauthorized access.
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
Feature
SAML
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.
PubDate