
Whether you're building an NGO portal, an Educational Website, or a website for publishing content on multiple channels, such as kiosks and mobile apps, Drupal is your best bet for a CMS. Across all scenarios, one thing stays constant - your precious content and data stored on the backend is fetched or accessed via APIs. 

These API endpoints must be protected.

This is where the [API Authentication Module](https://plugins.miniorange.com/drupal-rest-api-authentication) steps in. It provides a structured, reliable, and secure way to authenticate every request coming into your Drupal site, no matter where it originates.


## What Is Drupal API Authentication? {#waht-is-drupal-api-authentication}

Drupal API Authentication is the security layer that verifies every external request coming into your Drupal site, whether it's through core RESTful endpoints or JSON APIs. The authentication module checks who is making the call, which method they use to authenticate, then drupal decides whether they are allowed access, and how much they can do.

This ensures that only trusted clients can read or edit content through the RESTful or JSON API Endpoints.


## What can the miniOrange API Authentication module do? {#what-can-the-miniOrange-api-authentication-module-do}

At its core, it's a warden checking all incoming traffic - making sure there’s no bad actors getting in and gaining access to things they are not supposed to. 
Drupal REST & JSON API Authentication module supports the following authentication methods:
- **Basic Authentication:** The most straightforward option - send a username and password with the request to verify who’s accessing the APIs.
- **API Key Authentication:** Each client gets a unique key, and they include that key with every API call. It’s quick to set up and works well for lightweight integrations.
- **OAuth 2.0:** Majorly used in systems involving third-party applications, wherein it’s needed to access the resources on behalf of a user, without requiring the user to disclose their credentials to the third party. While OAuth 2.0 is only an authorization protocol, it is often combined with OpenID Connect (OIDC) to achieve authentication.
- **JWT Authentication:** These JSON Web Tokens (JWTs) are generated by the server and signed using a secret key. These contain critical information around user identification and client IDs. This token is passed alongside the request - and if the signature matches, data access is allowed.
- **Third party tokens:** Often, if you already use providers like Okta, Google or Entra id, you’ll be issued access tokens as a part of the OAuth2.0/OIDC flow. The module can accept these tokens as well and use them to authenticate the origin of API requests.

**BTS Automations -**
The module can also take care of a few important things for you - We’re talking token expiry, rotation and invalidation. This ensures that there’s minimal risk and your external apps can stay connected securely over time; without manual intervention. 

**Complete Control -** 
Beyond authentication, the module also gives you fine-grained control over how, where, and by whom your APIs can be accessed. You can define custom request headers, set your own token expiry durations, and create endpoint level restrictions for different clients.

Security can be tightened even further using IP based allow / deny rules or role-based access controls - ensuring that only the right systems, in the right context, can reach your Drupal APIs.

We’ve covered what the module can do. But a weapon or in this case - a shield - is useless unless you know how to wield it. So let’s talk about the hows, the wheres and the whys. 



## Why to use the API Authentication Module? {#why-to-use-the-api-authentication-module}
We’ve already talked about the different authentication methods, but let’s quickly summarise why a particular method should be used. 
**API Key Authentication:** a simple server-to-server integration or an internal tool, It’s quick to set up and straightforward to use.

**JWT Authentication:** when you want fast, stateless, and scalable authentication - especially for mobile apps, Single Page Applications (SPAs), and for decoupled configurations - more on this below. It involves a signed JWT token - And the best part? The module gives you 2 options for signing the JWT: either you can have it signed by your own externally generated key or you can let the module create the keys automatically during the setup.
**OAuth 2.0 Token Authentication:** when you have an integration with a third-party, and you need it to access the system's resources, but do not want to expose the user credentials. Pair perfectly with [OAuth / OIDC](https://plugins.miniorange.com/drupal-sso-oauth-openid-single-sign-on) based SSO setups.

Each method has its strengths, and the module gives you the freedom to pick what aligns with your architecture, compliance req and level of security.

But the module goes beyond API Authentication.
- It can authenticate JSON APIs as well.
- You can use it to restrict access to custom written APIs
- Configure role based access control - The user's role would decide the level of access and permissions that you wish to grant to your REST APIs for the Drupal site.
- If you wish to whitelist / exclude a few APIs from authentication, you can do so.
- And if you wish to block requests from an IP address, that’s possible as well.

But, perhaps the best way to use the API Authentication module, is by leveraging one of the main reasons why Drupal is chosen as a Primary CMS. 
  
## Paying heed to the headless {#paying-heed-to-the-headless}

One of the biggest strengths of having Drupal as your CMS is the ability to run Headless / Decoupled setups. In such setups, Drupal is the backend engine powering the content and authentication for multiple frontends - a mobile app, a react website etc. and that can quickly become messy and inconsistent. Every piece of content or user information is delivered through APIs - which means those APIs must be protected just as tightly as the main website.

This is where Headless SSO and API Authentication work together. 

Users login just once through an IdP (Azure AD, Keycloak, Okta, or miniOrange) and receive a token that each frontend can use. But, even with SSO Drupal still needs to validate every API request - confirming the token, the user, and what they’re allowed to access.

Without API authentication, decoupled systems risk running exposing, open, unauthenticated, and easily misused endpoints. 

API Authentication becomes the enforcement layer: it verifies the SSO token, ensures only trusted apps can call your APIs, and keep your data protected across channels - making it unified.


## Conclusion {#conclusion}

The Drupal Rest & JSON API Authentication module is built for modern architectures - headless, decoupled, multisite, and multi-channel. It strengthens your API security while giving you the flexibility to choose the right authentication method for every use case. 

This module ensures every request is authenticated, every token is validated and your data stays protected. 
 

Build NGO portals, educational sites, or multi-channel publishing platforms with Drupal—securely accessing backend content through powerful APIs.

What is API Authentication in Drupal?


## The problem nobody notices until it's too late. {#the-problem-nobody-notices-until-its-too-late}

Every organisation keeps accounts it no longer needs. Contractors leave, interns graduate, support vendors rotate out - but their creds often remain active across apps, websites, and services. These ‘digital zombies’ sit dormant, forgotten, and dangerous: easy targets for attackers, insider misuse, or accidental data exposure. Left unchecked, they become a silent vector for data leaks, compliance failures, and costly audits.

Our Drupal User Provisioning module eliminates digital zombies by keeping accounts in sync with your central identity system. When someone joins, their access is granted everywhere they need it and when they leave, it’s automatically revoked across all connected sites.

## What are digital zombies? {#what-are-digital-zombies}

Digital zombies are user accounts that are still active even though the person or process that needed them are gone or no longer exist/authorised. They look like normal accounts in your user list, but functionally they're an empty seat that still has a lot of privileges. 

They can bypass and/or slip past account audits because they appear normal in the long user list.

## What creates a Zombie Account? {#what-creates-a-zombie-account}
**Manual Processes:**
- If the IT or Human Resources department is manually creating accounts for all new hires across systems, they also have to manually disable the accounts when the person inevitably moves on.

**Forgotten Accounts:**
- Third party vendors and contractors are given temporary access, but their access is never revoked.
- Accounts created for testing or integration purposes and are orphaned and never deleted.

**Dormant Access:** 
- A person's roles get changed but their access rights still stay active, and these rights are never audited to      revoke unnecessary access.
  
## What happens when these accounts are left unchecked? {#what-happens-when-these-accounts-are-left-unchecked}

Forgotten accounts are not just something that takes up space in your database. They are dormant parasites that can create real risk:

**Unauthorized Access & Data Theft:**
- Attackers look for low - effort entry points; an abandoned, unattended, inconspicuous account with high privileges is an easy target.
- Once in, attackers can move through the system and exfiltrate data as and when required.

**Compliance Violations:**
- Regulations like GDPR, SOC2, HIPAA require timely access auditing - These forgotten zombie accounts can trigger penalties or block you from passing a compliance check at all.

**Overpaying for Licences:**
- If you’re using a tool which has a user-based billing, then you might end up overpaying for licence seats that are being blocked/consumed by dormant accounts, costing you hundreds if not thousands of dollars a month.

The solution? Something that can automate the process of user account creation and deletion i.e. Automatic User Provisioning and De-provisioning. 
Perhaps, something like the [**Drupal User Provisioning & Sync Module.**](https://www.drupal.org/project/user_provisioning)

Our User Provisioning module is a complete solution that automates the entire user lifecycle - from onboarding to offboarding. When a new employee joins, their account and roles are automatically created in Drupal by syncing with the central identity provider (through SCIM or APIs).

The module also has provisions using which you can decide when this Syncing occurs. You can either set it to happen as and when someone requests access to the system - Provisioning on demand.
Or you can have it occur in real time - immediately after any changes (CRUD Operations) take place.
Or to eliminate repeated processes, you can have it run at a specific time - based on a scheduler.

## The Benefit? {#the-benefit}

**Data consistency across all services.**

Any updates, changes to the role, group or any attribute of the user, are reflected across all connected sites.

**Automatic Creation and Deletion of Accounts.**

When the employee leaves, their account is automatically deprovisioned / disabled or removed from everywhere - closing the risk window of forgetting ‘zombie’ accounts. 
This also reduces overhead on the IT and HR departments.


**Auditing**

The module maintains a full audit trail of every action - success and failure - and provides admin notifications. 


**Final Thoughts**

Having the Drupal User Provisioning and Sync module run defence for you ensures all the users are accounted for, their access rights audited, and eliminates human error all the while giving the organisations something to maintain security and achieve compliance without manual effort.
 
That means - No more forgotten doors left open for attackers; No more data breaches; And No more compliance red flags; 

Take proactive steps today and make zombie accounts a thing of the past.

And if you want an even higher level of security - you can start by adding [SSO](https://plugins.miniorange.com/drupal-saml-single-sign-on-sso) and [MFA](https://plugins.miniorange.com/drupal-two-factor-authentication-2fa) to secure the way the users log in.

Stop leaving the doors open for attackers. Protect your Drupal site with automated provisioning that creates, updates, and removes user accounts in sync with your identity system.

Protect your Drupal Sites with Automated Provisioning


### Introduction {#Introduction}

 We have all done it  - we log into a service - that too on a shared device - and when we’re done with it, we simply close the browser tab and walk away thinking we’ve been automatically logged out, since an active session does not exist anymore. This is like unlocking the door to your house, and leaving the keys in the lock when you leave. Not a secure way to live, is it now?

But maybe you’re a bit smarter than the average joe, and you do remember to log out from a shared device once you’re done with it. But what if the system you’re using isn't that smart? 
You log out of one app only to discover you're still signed in on another.

That’s a Zombie Session. Still alive, and still accessible. One of the scariest gaps in your site's security. They are an open invitation for misuse and theft. 

**And Attackers love forgotten sessions.**

But there is a solution - a long lived concept - Single Logout or SLO, for short. This is nothing new. But we’ve gone a step further and have given it a glow-up. 

When a user manually logs out, the drupal session is terminated and assuming SLO is configured, the IDP session would be terminated as well. We just add bit out added security, and invalidate the token to prevent misuse. 

The new and improved miniOrange Drupal OAuth Client Module, makes SLO smarter, by linking user sessions directly to the Access or ID token - specifically the token expiry. This automatically triggers SLO when your token expires. 

That brings us to idle sessions. They need to be handled separately. We can take care of it using a setting in the Session Management module - the auto-logout. 
You can set a threshold value (in seconds) for inactivity, and if a user remains inactive beyond the configured time, auto-logout will take place first, and then SLO will follow to ensure the session is fully terminated from the IdP side as well. 

Let’s take a look at the components involved:  

###  What’s an ID Token? {#What’s-an-ID-Token?} 

You can think of it as your temporary pass/token - it is a digitally signed piece of information issued by the IdP after a user is successfully authenticated via something like OIDC. It contains details like the user’s identity, authentication time, and a set expiry. 

###  How long does a session last or what is Session Timeout? {#What-is-Session-Timeout-or-what-is-Session-Timeout?}

Session Timeout - It defines how long a user’s login session remains active on a site/application before it expires. By default, drupal has its own session timeouts. But with OAuth client, the drupal session timeout is directly synchronized with the Access or ID token expiry. 

###  What is Single Log Out? {#What-is-Single-Log-Out?}

Single Log Out (SLO) is a process that ends active sessions across all connected applications in one go. When triggered, it logs the user out from not just SP, but also from the Identity Source, and based on the configurations IDP - any other apps linked to it.

###  Smarter SLO {#Smarter-SLO}

You can configure SLO through the **miniOrange Drupal OAuth Client** Module. [Here’s the link](https://www.drupal.org/docs/contributed-modules/drupal-oauth-openid-connect-login-oauth2-client-sso-login/oauth-feature-handbook/single-logout-slo-configuration-between-drupal-and-okta) to a guide that outlines how you can configure SLO between Drupal and Okta. 

This is where it gets better - 
The OAuth Server issues an Access or ID Token when a user signs in. That token has a set expiry, that’s standard. 
When a user logs in, their session is created in Drupal. This session too, has a defined expiry. 

What if the *expiries* were to figuratively sync up? 

The OAuth Client Module, reads the token expiry and when the token expires, the module kills the Drupal session as well.
And now, the SLO comes into play to log the user out of other connected apps too (again, this depends on the IDP / OAuth Provider you’re using) - for example, logging out of your Gmail session, kills all sessions across YouTube, Google Sheets and the entire suite of apps, connected to Google - the Identity Source. 

The beauty of this feature? You don’t have to configure timeouts in a dozen places. The IdP sets the rule (default: 60 mins), and Drupal follows it. 


**The bottom line?**

No extra clicks. No zombie sessions. No loose ends. 

Users don't have to wonder if they are still logged in somewhere.
As there would be no forgotten sessions there would be fewer attack opportunities.

And.. that’s pretty much it: 
Your risk of zombie sessions is eliminated; your site stays secure and your sessions stay in sync.
 
If you’re already a part of our miniOrange Drupal Community, upgrade to the [latest version](https://portal.miniorange.com/downloads) right away. 
If not, we’d love to have you on-board! 

Here’s a [link](https://plugins.miniorange.com/drupal-sso-oauth-openid-single-sign-on) to know more. But if you’d like this out for a test drive, we can get you set up with a 7-day trial.

Discover how Single Logout (SLO) in Drupal enhances security by syncing session expiry with token expiry. Eliminate dormant sessions, prevent misuse, and ensure secure logouts across all connected applications.

Redefining SLO - Secure Logouts


### What it is and What it could be {#What it is and What it could be}

Right now, the world’s split into 2 - one half has got cash to throw at the most expensive solution, hoping it would be the best there is; and the other half never seems to have enough cash lying around that can be spent on a security solution. 

But there’s one thing that unites both these classes, it is their pre-existing infrastructure. Okay maybe there are 2 things. Both classes fail to realize that the set-up that they’ve already got - the website; presumably built on Drupal - the best CMS there is when it comes to security - and the associated database - can in itself become the source for Identity Verification or in other words, Drupal becomes your Identity Provider (IdP). 

### Unmasking Cloud IdPs {#Unmasking Cloud IdPs}

When faced with the daunting task of setting up a centralized Identity Management System, most people turn to providers like Azure AD, Okta and Ping Identity to name a few.
While there’s nothing inherently wrong with choosing these products - they exist for a reason, they have a great product that has stood strong for tens of years. But what the average consumer of these services do not realize, is how quickly the costs can add up. 

Maybe you’re someone who is into finance, maybe not, but there’s this concept of NDR - Net Dollar Retention - which literally means how much a customer is paying year over year. Any NDR over 100% is a sign of growth and expansion of business. There are many ways to achieve a 100%+ NDR, you cross-sell or you up-sell, but the easiest way might just be to simply jack up the prices. That is what the leaders tend to do - and they can get away with it, just because there’s nowhere for the users to go, there isn’t a better alternative out there. Well, until now. 

### Why On-Prem Drupal IdP {#Why On-Prem Drupal IdP}

IdPs like Okta and Azure are feature-rich no doubt, but they’re often priced for large organizations. miniOrange provides a powerful, scalable alternative that doesn’t break your bank; and the added benefit - it sits right in your Drupal Ecosystem!

Let’s talk numbers:

**Cloud SaaS Solutions:** $5 to $15 per user per month - That’s anywhere between $6000 to $18000/year for 100 users. Even if we consider a non-linear pricing model, a 50% reduction would still mean an annual cost of anywhere between $3000 and $9000. 

**[On-Prem Drupal as IdP](https://plugins.miniorange.com/drupal-saml-idp):** $450/year for 100 users.
That's over 90% savings, without compromising on security or features. It's got all things you’d expect out of a full-fledged cloud IdP -
   1. Adaptive Authentication? Check! 
   2. Protocol Agnostic - If you’re a [SAML](https://plugins.miniorange.com/drupal-saml-idp) junkie or an [OAuth](https://plugins.miniorange.com/drupal-oauth-server) groupie, it can do both! Check, and Check!
   3. Auditing, Logging and [Session Monitoring](https://plugins.miniorange.com/drupal-session-management)? We got that too!
   4. In-built MFA support? Yep, it’s got that as well

There’s a pretty significant trade off while choosing between a cloud or an on-premise solution - especially when it comes to authentication & user security. One often-overlooked but critical factor in this decision is data residency.

With the rampant expansion of the AI landscape, where the ethics of AI crawlers are questionable, you should ask yourself is your cloud hosted data really private?

Why not shift to a solution that is completely within your control? A solution that can work without any external connectivity, a solution that gives you your very own inhouse IdP without the pesky setup, a solution that makes financial and technological sense.

When it comes to creating an IdP within Drupal, there are solutions including the likes of us where everything is deployed completely on-premise, within your own infrastructure - with no risk of user data exposure or a leak. The entire identity flow stays inside your environment, giving you complete control over your security setup - nothing ever leaves your system.


### Put your money where it matters {#Put your money where it matters}

This level of control is not just a bonus, it's elementary - almost mandatory, especially if you're aiming for SOC2 compliance, or operating in an environment where data sovereignty is a legal or internal mandate.

And if you need even more convincing, here’s the kicker - by going for these solutions - you're just not improving security; you're saving a ton to what you'd otherwise be spending on external identity services. 
The money you save just doesn't disappear, it can be redirected to something more meaningful, like adding advanced capabilities such as a [PAM](https://www.miniorange.com/pam/) solution, or maybe even back into your team - because who doesn’t like a fatter wallet? Sometimes the best investment you can do is just giving your employees a well-deserved raise.

**The bottom line?**

You don't have to overspend to get a reliable and secure IAM solution, without - now you have the power, you can do it all - we believe in you!


Tired of high costs from cloud-based Identity Providers? Learn how your Drupal site can become a secure, affordable on-premise Identity Provider (IdP) saving money and giving you full control.

Drupal

What is API Authentication in Drupal?

Protect your Drupal Sites with Automated Provisioning

Redefining SLO - Secure Logouts

How You Can Save Big With Drupal As Your Identity Provider