PMQ.Identity

685 downloads · 28 files, 1,488 lines · repository

A provider-agnostic identity module. Two modes: external, with a token from a central provider over OIDC, and local, with a JWT issued by the application itself.

The problem

A small application starts out issuing its own token, because it is the shortest path. When the company standardizes on a central identity provider, each application needs its authentication part rewritten, and that part is scattered everywhere that reads the user.

I lived both sides of that migration in a landscape with hundreds of applications at different stages, and that is where the design comes from.

The decision

The mode is configuration, not architecture. The application works with an identity abstraction, and whether the token comes from an external provider or is issued locally sits in an IdentityMode with two isolated configuration paths, ExternalSettings and LocalSettings, each with its own IdentitySetup. Switching one for the other stops being a rewrite and becomes one line.

What that solves in practice: a new application is born in local mode, without depending on anyone provisioning a client in the central provider; when standardization arrives, it switches modes without any code that reads the user changing.

Configurable claim mapping. Identity providers do not agree on the name of the claim that carries role, identifier or tenant, and each one solves it its own way. Leaving that map in configuration, the ClaimsMappingOptions, avoids switching providers forcing a hunt for magic strings scattered through the code.

The limit

The local mode exists for the short path and for development, not to be an identity provider. It issues and validates JWTs; it does not do federation, does not manage consent, does not rotate keys by itself. An application that needs that should use a real provider, which is exactly what the external mode expects.