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

legacy auth baseline+25%

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.