Modern SSO and OAuth Enablement

Goal

Introduce modern SSO while preserving established capability

The goal was not simply to add an OAuth library. It was to separate how a person or service authenticated from how the application represented that identity.

That boundary needed to support interactive and service-to-service journeys across ASP.NET Core services, established IIS-hosted services, desktop applications and newer web experiences. It also needed to retain compatibility for components that still depended on Windows authentication while enabling OIDC and JWT-based access at modernised boundaries.

Method

Normalise identity, then modernise each boundary

Usernames were normalised from DOMAIN\user to User Principal Name (UPN) format so that identity could be represented consistently beyond Windows domain boundaries. A stable numeric application-level user identifier was introduced for foreign-key relationships, allowing authentication names to change without making those names the durable key used throughout the application.

That identity change reached across hundreds of tables and an extensive set of stored procedures. Pre-migration and post-migration scripts introduced the new relationships in controlled stages, preserved referential integrity and allowed the established and new identity representations to coexist while dependent components were updated.

MSAL.NET and Microsoft.Identity libraries replaced Windows-specific authentication libraries at modernised boundaries. Application registrations and service principals represented interactive clients, hosted applications, APIs and service identities in Microsoft Entra ID.

The hybrid directory strategy was assessed alongside the application changes. Microsoft Entra Cloud Sync provided the route from on-premises Active Directory, while pass-through authentication and password hash synchronisation were compared against user experience, service dependencies, resilience and operational support requirements rather than treated as interchangeable defaults.

The authentication flow was made explicit for each journey:

• Public-client flows supported interactive clients that could not safely hold a secret.
• Confidential-client flows supported server-side applications and services able to protect their credentials.
• Client-credentials flows supported service-to-service calls without a signed-in user.
• On-behalf-of (OBO) flows allowed an API to request a downstream token while preserving the delegated user journey.

Application-permission grants and RBAC assignments were brought into deployment automation alongside application configuration. Within the core application, asynchronous local context carried the authenticated application identity across asynchronous operations instead of falling back to implicit Windows state.

Technical Challenges

Identity across the application journey

The hardest part was coexistence. Existing services and identity records still used domain usernames while newer components received OAuth tokens. A single user journey could cross web, API and desktop boundaries, including established WinForms functionality delivered through Citrix or Azure Virtual Desktop.

Deployment also became part of the identity design. Application registrations, service principals, grants and role assignments had to remain aligned with the software using them. Treating those objects as manual tenant configuration would have made repeatable environments and controlled change more challenging.

Deployment pipelines therefore applied Infrastructure as Code, including Terraform, and Configuration as Code so that identity resources, permissions and environment configuration could be versioned and deployed consistently. Usernames were normalised through DACPAC pre-migration and post-migration scripts. The staged approach kept each intermediate state visible: which components accepted tokens, which still required Windows identity, which usernames had been normalised to UPN format, where stable application identifiers were in use, and where identity translation still occurred.

Outcomes

A working route to modern authentication

Modern web and API components gained a route to OIDC, OAuth and JWT-based authentication, while established components continued to operate using Windows AD until they were themselves converted. User and service journeys could use the flow appropriate to their security context, and the application resolved identity through a stable internal identifier rather than relying on every caller having a Windows account.

The result was a smaller, lower-risk migration path with defined routes to rollback if necessary. Authentication technology could evolve at controlled boundaries instead of forcing simultaneous change across the platform.

Business benefits

Protect existing investment while enabling new journeys

• Modern SSO without a platform-wide authentication rewrite.
• A stable application identity decoupled from Windows username formats.
• Clear separation between interactive, delegated and service authentication flows.
• Repeatable deployment of the identity objects and permissions on which applications depended.
• Safer coexistence between established desktop capability and newer web and API services.
• A stronger foundation for later external-identity and cloud-hosting work.

Architecture value

Architecture made incremental change possible

Authentication affected user identity, applications, services, permissions and deployment. Architecture created boundaries that allowed those concerns to move at different rates while retaining a coherent identity model, repeatable environments and defined rollback routes. That turned a potentially platform-wide rewrite into a controlled modernisation programme.