architecture · Aug 2024 – Oct 2024
Replacing Legacy Auth with Azure AD / Microsoft Entra ID
Migrated enterprise authentication to Azure AD / Microsoft Entra ID across multiple applications — login performance +25% — with OAuth2 and RBAC.
- Role
- Implemented the OIDC integration, OAuth2 flows, and role-based access control
- Team
- Enterprise applications team
- Scope
- Authentication and authorization across multiple enterprise applications at Indigo (InterGlobe Aviation)
- Level
- Digital Consultant — Full Stack Developer
Login performance
Method: Compared sign-in latency on the standardized Entra ID flow against the legacy per-app logins it replaced.
Window: post-migration
Context
At Indigo (InterGlobe Aviation) I worked across several enterprise applications, each carrying its own legacy authentication. Duplicated login logic, inconsistent sessions, a fragmented sign-in experience — the usual cost of auth that grew app-by-app instead of being designed once.
The work was to replace all of it with Azure AD / Microsoft Entra ID as a single identity provider.
Why centralize on a standard
The tempting shortcut is to patch each app's slow login individually. But that leaves every application with its own auth code — its own bugs, its own session quirks, no single sign-on, no unified governance.
Standardizing on Entra ID over OIDC and OAuth2 replaced that bespoke logic with one well-optimized standard flow. That's where the 25% login-performance improvement came from: not a clever trick, but deleting a pile of slow custom code and replacing it with a standard the identity provider has already optimized.
Authorization, not just authentication
Authentication answers who are you; authorization answers what can you do. I carried roles on the token and enforced RBAC consistently, so access decisions stopped being ad-hoc per-app logic and became uniform and auditable.
What broke
The honest part: an early token-validation config left token-lifetime and clock-skew tolerance on assumptions that didn't hold, which showed up as intermittent re-auth prompts in testing. Intermittent is the worst kind of auth bug to chase. The non-negotiable parts of validation — verifying the token signature against the provider's published keys and checking the issuer and audience claims — were never the problem; it was the timing assumptions. Once I made lifetime, refresh, and skew tolerance explicit, it was solid — and that's now the first thing I nail down on any OIDC integration.
Outcomes
Multiple enterprise applications moved onto a single governed identity layer with single sign-on, the standardized login flow measured about 25% faster than the legacy paths, and authorization became consistent across apps.
Decision Records
Where I Got It Wrong
Failure 1
An early token-validation configuration didn't fully account for token-lifetime and clock-skew tolerance, which surfaced as intermittent re-authentication prompts during integration testing
Cost: Extra back-and-forth in testing before the flow was solid enough to roll out
Lesson: Pin down token lifetime, refresh behavior, and clock-skew tolerance explicitly at the start of an OIDC integration — these are easy to leave on defaults and painful to debug as intermittent failures later
Long-Term Impact
Centralized identity gave the enterprise apps single sign-on and one place to govern access.