Modern applications often start with Azure AD (now Microsoft Entra ID) for authentication—and for good reason. It’s secure, battle-tested, and integrates seamlessly with Azure-native services.
But as systems grow, teams frequently hit a wall:
“We can authenticate users, but we can’t express our authorization logic cleanly using Entra ID claims alone.”
At that point, one architectural pattern comes into focus:
Validating the Azure AD token, then issuing your own application-specific JWT.
This post explains when this strategy makes sense, when it doesn’t, and how to implement it responsibly.
The Problem: Identity vs Authorization Drift
Azure AD excels at answering one question:
Who is this user?
It does this using:
- App roles
- Group membership
- Scopes
- Optional claims
However, real-world authorization often depends on things Azure AD cannot evaluate:
- Data stored in your application database
- Tenant-specific permissions
- Feature flags or subscription tiers
- Time-bound or contextual access rules
- Row-level or domain-specific authorization logic
Trying to force this logic into Entra ID frequently leads to:
- Role explosion
- Overloaded group membership
- Fragile claim mappings
- Slow iteration cycles
This is where many systems start to creak.
The Strategy: Token Exchange with an Application-Issued JWT
Instead of overloading Azure AD, you introduce a clear trust boundary.
High-level flow
- User authenticates with Azure AD
- Client receives an Azure-issued access token
- Your API fully validates that token
- Your API issues a new, short-lived JWT containing:
- Application-specific claims
- Computed permissions
- Domain-level roles
- Downstream services trust your issuer, not Azure AD directly
This is often referred to as:
- Token exchange
- Backend-for-Frontend (BFF) token
- Application-issued JWT
It’s a well-established pattern in enterprise and government systems.
Why This Works Well
1. Azure AD handles authentication; your app handles authorization
This separation keeps responsibilities clean:
- Azure AD → Identity proof
- Your API → Business authorization
You avoid pushing business logic into your identity provider, where it doesn’t belong.
2. You can issue dynamic, computed claims
Your API can:
- Query databases
- Apply complex logic
- Evaluate tenant state
- Calculate effective permissions
Azure AD cannot do this—and shouldn’t.
3. Downstream services stay simple
Instead of every service needing to understand:
- Azure tenants
- Scopes vs roles
- Group semantics
They simply trust:
- Your issuer
- Your claim contract
This dramatically simplifies internal service authorization.
4. Identity provider portability
If you later introduce:
- Entra B2C
- A second tenant
- External identity providers
Your internal JWT remains the stable contract.
Only the validation layer changes.
When This Is Overkill
This pattern is not always the right choice.
Avoid it if:
- App roles and groups already express your needs
- Authorization rules are static
- You don’t have downstream services
- You want minimal operational overhead
A second token adds complexity—don’t add it unless it earns its keep.
Security Rules You Must Follow
If you issue your own JWT, there are no shortcuts.
1. Fully validate the Azure token
Always validate:
- Signature
- Issuer
- Audience
- Expiration
- Required scopes or roles
If you skip any of these, the pattern collapses.
2. Keep your token short-lived
Best practice:
- 5–15 minute lifetime
- No refresh tokens (unless explicitly designed)
Azure AD should remain responsible for session longevity.
3. Protect and rotate signing keys
- Use a dedicated signing key
- Store it securely (Key Vault)
- Rotate it regularly
- Publish JWKS if multiple services validate your token
Your token is only as trustworthy as your key management.
4. Be disciplined with claims
Only include what downstream services actually need.
Avoid:
- Personally identifiable information
- Large payloads
- Debug or “just in case” claims
JWTs are not data containers.
A Practical Mental Model
A simple way to reason about this pattern:
Azure AD authenticates people.
Your application authorizes behavior.
If that statement matches your system’s reality, this approach is not only valid—it’s often the cleanest solution.
Final Thoughts
Issuing your own JWT after validating an Azure AD token is not a workaround or an anti-pattern. It’s a deliberate architectural choice used in:
- Regulated environments
- Multi-tenant SaaS platforms
- Government and municipal systems
- Complex internal platforms
Like all powerful patterns, it should be applied intentionally, with strong security discipline and a clear boundary of responsibility.
Used correctly, it restores simplicity where identity systems alone fall short.
Architecture Diagram (Conceptual)
Actors and trust boundaries:
- Client (Web / SPA / Mobile)
- Initiates sign-in using Microsoft Entra ID
- Receives an Azure AD access token
- Never handles application secrets or signing keys
- Microsoft Entra ID (Azure AD)
- Authenticates the user
- Issues a standards-based OAuth 2.0 / OpenID Connect token
- Acts as the external identity authority
- Authorization API (Your Backend)
- Validates the Azure AD token (issuer, audience, signature, expiry, scopes)
- Applies application-specific authorization logic
- Queries internal data sources (database, feature flags, tenant configuration)
- Issues a short-lived, application-signed JWT
- Downstream APIs / Services
- Trust only the application issuer
- Validate the application JWT using published signing keys (JWKS)
- Enforce authorization using domain-specific claims
Token flow:
- Azure AD token → proves identity
- Application-issued JWT → encodes authorization
This design creates a clean boundary where:
- Identity remains centralized and externally managed
- Authorization becomes explicit, testable, and owned by the application