OAuth 2.0, OIDC, SAML: An Architect's Field Guide to Federation Protocols

Protocol selection questions arrive weekly when you govern an enterprise application estate: the vendor supports three options, the project wants the quickest, and the architecture function has to care about the estate you are left with in five years. This is the working guide I give teams.

Know what each protocol is

• SAML 2.0 - XML-based federation for browser SSO. Mature, ubiquitous in enterprise SaaS, and perfectly serviceable for web single sign-on. It has no native story for APIs, mobile, or token exchange, and its cryptographic surface (XML signatures) has a long CVE history that demands disciplined library hygiene.
• OAuth 2.0 - not an authentication protocol. It is delegated authorisation: a framework for issuing scoped access tokens to clients. Anyone “logging users in with OAuth” alone has built a confused-deputy generator.
• OIDC - the identity layer on OAuth 2.0: ID tokens, standard claims, discovery. For anything new - web, native, SPA, API - OIDC with authorisation code flow and PKCE is the default answer.
• WS-Federation - legacy. Relevant only for ageing Microsoft-ecosystem applications; every instance in the estate should carry a deprecation date.

The decision table I actually use

New application with a choice: OIDC. Enterprise SaaS that only offers SAML: SAML, without agonising - it is fine for browser SSO. APIs and service-to-service: OAuth 2.0 client credentials with workload identities and short-lived tokens, never shared secrets in config. Native and single-page apps: authorisation code with PKCE, no exceptions, no implicit flow. Anything proposing resource owner password credentials: rejected, and the vendor conversation escalated - it defeats MFA, conditional access, and the entire signal-based model.

Govern the estate, not just the choice

The protocol decision is the easy part; the estate is where entropy wins. The governance controls that keep a federation landscape healthy:

• An onboarding standard per protocol - required flows, token lifetimes, signing algorithms, redirect URI rules - so each integration is a stamp, not a negotiation.
• An inventory of every relying party and its protocol, with owners. You cannot deprecate what you have not enumerated.
• Certificate and secret lifecycle managed centrally - SAML signing cert expiry remains the most reliably self-inflicted outage in enterprise IT.
• Claims and scope discipline - applications receive the minimum claims they need; “send everything, the app will pick” is a data leak with a schema.

Protocols are the plumbing of trust. Choose boringly, govern relentlessly, and save your creativity for the access model.