Bridging the Data Gap : Enhancing Entra ID Tokens with Custom Claims Providers
Introduction : The "Data Silo" Challenge
Imagine an organization managing a complex B2B collaboration. You are integrating multiple external applications using modern standards like SAML and OIDC.
However, a common challenge arises: Data Disconnect. While Microsoft Entra ID (formerly Azure AD) handles the authentication, it doesn't always hold every piece of information about a user. Critical attributes such as a user’s specific clearance level, a legacy account ID, or a dynamic spending limit often reside in external systems, on-premises SQL databases, or separate HR repositories.
If these attributes aren't in the Entra ID directory, Entra cannot, by default, inject them into the token. This leaves organizations stuck: do they force a risky migration of sensitive data to the cloud, or do they build complex, brittle workarounds?
The Solution : Entra as an Intelligent Identity Orchestrator
Microsoft Entra ID addresses this with a feature known as a Custom Claims Provider.
Think of this as a "live hook" during the authentication process. When a user logs in, Entra ID pauses the process momentarily to call a custom API (hosted on an Azure Function App). This function contains the logic to query your external repositories whether it’s an on-premise database or a third-party API to fetch the missing data.
Once the data is retrieved, the function sends it back to Entra ID. A Claims Mapping Policy then takes this data and seamlessly injects it into the SAML or OIDC token. The application receives a complete token with all necessary claims, unaware that the data came from disparate sources.
Why This is a Game Changer for Organizations
The primary value of this approach isn't just "connectivity", it is Security Strategy and Data Sovereignty.
Data Sovereignty & Privacy: Organizations often hold highly sensitive attributes (e.g., government clearance levels, patient data, or proprietary financial tiers) that policy dictates must remain on-premises or in a specific sovereign store. With Custom Claims Providers, you do not need to sync this sensitive data to the cloud. It stays in your secure local repository and is only fetched just-in-time for the token.
Support for Machine Identities: It’s not just for humans. Machine identities and service accounts often require dynamic attributes for authorization. This feature allows those attributes to be injected without permanently storing them in the directory.
Legacy Integration without Migration: You can modernize your authentication (using Entra ID) without modernizing your database immediately. It extends the life of legacy systems by making them compatible with modern SSO.
The Security Architecture
A common concern is the security of the API call itself: “How do we ensure the connection between Entra ID and our external data is safe?”
This is where the Microsoft ecosystem provides robust protection. The communication relies on Azure Managed Identities. When Entra ID calls your Azure Function, it presents a verified token. This means your function app does not need to be exposed to the public internet anonymously, it is configured to trust only your specific Entra ID instance. You get the full benefit of Microsoft’s enterprise-grade authentication backbone to secure the "bridge" between the cloud and your private data.
Conclusion : Secure Identity Without Compromise
The Entra Custom Claims Provider proves that you don't have to choose between cloud convenience and data sovereignty. By fetching sensitive attributes just-in-time, organizations can maintain a "Zero Trust" posture while keeping critical data in their own secure repositories. This isn't just a technical workaround, it’s a strategic way to modernize your identity stack while keeping your most sensitive information exactly where you trust it most.
Implementation
For those looking to deploy this architecture, Microsoft provides detailed documentation on configuring custom claims providers:
