← WordPress SSO and Identity: A Complete Guide
When should you use OAuth/OIDC instead of SAML?
When you’re connecting to a modern SaaS provider, a social login, or another application built around REST and JSON rather than XML, OAuth 2.0 and OpenID Connect are the native fit. SAML still dominates traditional enterprise IdPs (Okta, Azure AD, OneLogin); OAuth/OIDC is the default everywhere the ecosystem is more web-native.
OAuth 2.0 vs OpenID Connect
OAuth 2.0 is an authorization protocol: it’s built to grant access to a resource (an API, a piece of data) on a user’s behalf, not to establish identity by itself. OpenID Connect is a thin identity layer built on top of OAuth 2.0 that adds a standardized way to actually confirm who the user is, via an ID token, not just what they’re authorized to access. For SSO specifically, you almost always want OIDC, not bare OAuth, because OAuth alone doesn’t guarantee you’re getting a verified identity back.
WordPress as an OAuth client
Most WordPress SSO scenarios put WordPress in the client role: it redirects a user to an external OIDC provider, receives an authorization code, exchanges it for tokens, and uses the ID token to establish who the user is and log them in. This is the more common setup, since it lets WordPress delegate authentication to whatever identity system an organization already runs.
WordPress as an OAuth/OIDC provider
Less common, but real: WordPress itself becomes the identity provider, issuing tokens that other applications trust. This is the pattern behind giving one WordPress login access to several connected apps, where WordPress is the source of truth for identity and every other application defers to it. That’s a meaningfully bigger build than being a client, since WordPress now has to implement the provider side of the protocol correctly, including token issuance and revocation.
See single sign-on across connected apps for what that looks like as a real build.
Token handling and security
Access tokens and ID tokens need short lifetimes and a real refresh strategy, not tokens that live forever because rotating them was inconvenient to build. Tokens need to be validated properly (signature, issuer, audience, expiration) on every use, not just accepted at face value because they arrived in the right format. Getting this layer wrong is a real security exposure, not a minor detail, since a forged or replayed token is exactly what an attacker wants to hand you.
Talk to 84EM about a custom OAuth/OIDC integration if your identity provider needs more than a stock plugin’s defaults.
