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