DDEV is the official local development tool of Drupal. And like Drupal, DDEV depends on the support of the open source community.
By miniOrange Inc on
Authenticating Users stored in a Popular, Custom Identity Provider (IdP) and enable Single Sign On. Pretty straightforward right?
How about performing the authentication using PKCE / PIXY OAuth flow? A little less so.
And now add Headless or Decoupled Drupal into the mix. Things start to look a lot murky.
This is the exact scenario that is solved in this nifty little solution. We added Single Sign On (SSO) using OAuth - PKCE protocol in a Headless / Decoupled Drupal system.
Why Drupal was chosen:
Drupal is one of the top CMS choices. And with the option of opting for a Decoupled Drupal website, it was the obvious choice for the organization.
-
It provides a highly flexible and scalable development foundation that can be customized to the organization's specific needs.
-
The Drupal modules customized to devise the solutions are pre-existing extensions on Drupal itself.
-
It's an open source software with no licensing costs
Describe the project (goals, requirements and outcome):
The Technology Used:
Front End - ReactJS
Back End - Drupal 9.x
miniOrange Modules:
Headless Drupal is the OAuth Client here. The users are authenticated by a Popular Custom OAuth Server, which only supports PKCE Authentication Flow, as opposed to the Standard Authorization Grants.
The Solution:
The authentication system has 3 major components namely, the ReactJS Front End, Drupal 9.x Back End and the Custom OAuth Server.
The user will be logging into the Drupal System using the credentials of the Server.
Stage 1:
The User starts the Login Process from the ReactJS login Page. On the Login form, once they click on the secure Login button, the flow is redirected to the Drupal Backend.
When the Login process is started, a couple of strings are generated -
Code Verifier and Code Challenge.
This Code Challenge is then sent along with the call to the Authorization End Point of the OAuth Server.
Stage 2:
The user is then able to see the Server Login page, wherein they type in the credentials.
After User Credentials verification, an Authorization Code is generated. This Authorization Code is then sent back to the Drupal Backend.
Stage 3:
The same Authorization Code is then sent back to the Server along with the Code Verifier.
The Code Verifier and Code Challenge authentication is done by the OAuth Server. This ensures that the request is originating from the correct / authentic / expected source.
Stage 4:
After verifying the Code Verifier and the Code Challenge strings, the Server generates an Access Token, which is sent back to the Drupal Backend.
Having the Access Token, allows the requisitioner to access the user data, as put forth in the Scope - a parameter which is sent with the Authorization Code (In Stage 3). This is sent to the userInfo endpoint in the Server.
Stage 5:
The Server, sends back the user information, as requested in the Scope parameter.
Upon receiving the requested user information, a session is created in the Drupal Backend using the said information.
At this stage, the User Session is created in the backend, but the frontend hasn’t yet been notified of this development.
As an added layer of security for session management, we added another token verification step while creating the session for the user in the Front End.
Stage 6:
A token is generated for each user after creating their session in the Backend. This token is sent to the front end upon redirection. The miniOrange Drupal RestAPI Authentication module sits on top of the Drupal Backend. The RestAPI module, receives the API call and the ID Token from the front end.
The module authenticates the source of the API call, and then forwards the request - to Drupal backend - if it has originated from an authenticated source - adding another layer of security.
And the Drupal backend responds back to the Front End once the request task has been completed - in this case, the Front End is notified that the User has been authenticated and logged in.
System Flow:
Fig1.1 OAuth PKCE SSO Flow in Headless Drupal System
Technical specifications
Drupal version:
Drupal 8.x
Drupal 9.x
Drupal 10.x
Key modules/theme/distribution used:
Why these modules/theme/distribution were chosen:
The Organization already had a custom IdP - which only supports the PKCE Authorization Flow. Naturally, the obvious choice for SSO was the miniOrange Drupal OAuth module.
And in a bid to add another layer of security - authenticate the source of the API calls coming from the frontend - we added the RestAPI Authentication module.
Organizations involved:
Team members:
Sectors:
Government
Technology
