Security

Identity Provider & SSO (Entra ID / OIDC)

Intermediate

Authentication is already solved, by specialists, over decades. Use a proven identity provider and standard protocols (Entra ID / OpenID Connect / OAuth 2.0) instead of building your own login, token format, or session scheme. Hand-built auth is where small but serious mistakes hide, and it is almost never worth it.

A managed identity provider gives you MFA, conditional access, account lifecycle, brute-force protection, key rotation, token revocation, and federation — built correctly and kept up to date — for free. Building any of that yourself means writing security-critical code that the whole company then depends on, and getting it as right as a dedicated vendor, forever.

The Finperiti audit is the warning: authentication was a home-built symmetric HS256 JWT scheme with a single shared secret, instead of Entra ID / MSAL SSO. A shared symmetric secret means anyone who can validate a token can forge one, and one leak compromises every tenant. A proper IdP with asymmetric, rotated keys removes that failure mode. Standardise on the IdP and integrate cleanly with it.

Use a proven identity provider

AlwaysAuthenticate through the standard identity provider (Entra ID) using OpenID Connect / OAuth 2.0 and the official libraries (MSAL). Do not build your own login or token-issuing scheme.
DoLet the IdP own the hard parts: MFA, conditional access, password policy, lockout, account lifecycle, and consent. Configure them. Do not rebuild them.
DoUse SSO, so people authenticate once against one identity, and joiners, movers, and leavers flow through a single source of truth (see Identity & Account Hygiene).
DoValidate tokens with the IdP's published (asymmetric) signing keys and follow rotation through its JWKS endpoint, so there is no shared secret to leak or forge with (see Session & Token Management).
ConsiderFederating customer/B2B identities through the IdP (external identities / B2B) instead of keeping a separate user store and password database.
AvoidKeeping your own username and password store when the IdP can own identity. Every password you store is a breach risk you did not need.
NeverRoll your own authentication, token format, or session scheme, or sign tokens with a single shared symmetric secret, for anything handling real users or data.

Home-rolled symmetric JWT

// shared secret in config, same across tenants/environments
var token = JwtBuilder.Create().WithSecret("shared-hs256-secret")
           .AddClaim("role","admin").Encode();

Symmetric signing means anyone who holds the secret can mint admin tokens, and one leak breaks every tenant — the Finperiti finding. There is also no MFA, lockout, revocation, or rotation. All of it is rebuilt, badly.

Entra ID via MSAL / OIDC

// app delegates auth to Entra ID and validates tokens against its JWKS
builder.Services.AddAuthentication().AddMicrosoftIdentityWebApi(config);
// tokens are asymmetrically signed, with MFA and conditional access enforced by the IdP

MFA, lockout, rotation, and revocation come from the IdP. Tokens are asymmetrically signed, so verifiers cannot forge. There is no shared secret to leak. Far less code, far more secure.

Integrate cleanly

DoUse the standard flows (authorization code with PKCE for interactive apps; client credentials or managed identity for service-to-service). Never improvise a flow.
DoTake identity, roles, and tenant from validated IdP claims, and keep authorisation decisions in your app. The IdP says who you are; you decide what they may do.
DoKeep IdP client secrets and certificates in the vault and rotate them, or use managed identity / workload identity federation to avoid secrets entirely.
ConsiderCentralising token validation in shared middleware, so every endpoint validates the same way and none can skip it.
NeverDisable issuer, audience, signature, or expiry validation, or accept tokens from an untrusted issuer.

Self-review checklist

AskAm I using the IdP and standard protocols, or rebuilding any part of authentication?
AskIs any shared symmetric secret signing tokens, or is there a password store I could avoid?
AskAre tokens validated against the IdP's rotating asymmetric keys (issuer, audience, expiry)?
AskDo MFA, lockout, and account lifecycle come from the IdP rather than my code?

Why it matters: Authentication is high-stakes and harder than it looks. The failure modes — forgeable tokens, no revocation, missing MFA, shared secrets — are exactly what sank the Finperiti auth design. A proven identity provider gives us correct, maintained, certifiable authentication out of the box, frees us from storing passwords and secrets, and removes a whole class of breach we would otherwise own forever.