architecture · Sep 2024 – Oct 2024

Replacing Legacy Logins with Azure AD Across Multiple Applications

Integrated Azure Active Directory authentication across multiple applications at Indigo, retiring the legacy logins and improving login performance by 25%.

Role
Implemented the Azure AD integration, OAuth2/OIDC flows, and token-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

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 Active Directory as a single identity provider. (Alongside it, I replaced legacy scheduler-based jobs with flight-data synchronization web services, improving sync performance by 8%.)

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 Azure AD 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.