Identity & Access Management
SSO & Identity Federation
Federation lets a user authenticate once at an Identity Provider (IdP) and access many Service Providers (SPs) without re-entering credentials, via an out-of-band trust relationship — SAML remains the enterprise default, OIDC (Oauth2 And Openid Connect) the modern one for anything new.
- Federation separates where a user authenticates (the IdP) from what they access (many SPs) — trust between them is established out-of-band via exchanged metadata and certificates, not per-login
- SAML (XML assertions over browser redirects) is still the enterprise-SSO backbone for many established identity stacks; OIDC (JSON/JWT on top of OAuth 2.0) is the default choice for anything built new
- Just-in-time (JIT) provisioning creates or updates a local user record from the attributes in an IdP assertion on first login, instead of requiring an admin to pre-create every account
- SCIM standardizes user/group lifecycle sync (create, update, deactivate) between the IdP and downstream apps — it closes the gap SSO alone leaves open: the employee left the company, but their access in a dozen SaaS apps was never revoked
- SP-initiated flows start at the service provider, which redirects to the IdP; IdP-initiated flows start at the identity provider's own portal — the distinction matters for CSRF-style protections carried in
RelayState(SAML) orstate(OIDC) - Federation moves trust, it does not eliminate it: a compromised IdP session — or the IdP itself — compromises every federated SP behind it at once, making the IdP the single highest-value target in the whole system
| SAML | OIDC | |
|---|---|---|
| Format | XML | JSON / JWT |
| Transport | Browser redirect + POST binding | OAuth 2.0 redirects + token endpoint |
| Primary use case | Enterprise SSO into legacy/established stacks | Modern web/mobile apps, consumer + enterprise |
| Token type | Signed XML assertion | ID token (JWT) + access token |
JIT provisioning trades administrative overhead for a different risk: since the local record is built from whatever attributes the assertion carries, an SP must treat the IdP as the source of truth for those attributes and re-evaluate them on every login — a stale local copy of group membership from six months ago silently drifts from what the IdP would say today.