← WordPress SSO and Identity: A Complete Guide
How does SAML SSO work with WordPress?
WordPress acts as a service provider: a user authenticates with an enterprise identity provider (Okta, Azure AD, OneLogin, or similar), the IdP sends back a signed assertion confirming who they are, and WordPress logs them in and maps their IdP groups to WordPress roles, no separate WordPress password involved.
WordPress as a SAML service provider
In SAML 2.0 terms, the identity provider (IdP) is the system that authenticates the user, and the service provider (SP) is the application granting access based on that authentication. WordPress plays the SP role: it redirects an unauthenticated user to the IdP, receives a signed assertion back confirming identity and (usually) group membership, validates that signature, and creates or logs in the corresponding WordPress user.
Connecting to Okta, Azure AD, OneLogin
Each enterprise IdP has its own admin console for configuring a SAML application, but the pieces are the same everywhere: an entity ID and metadata URL for WordPress, the SP’s assertion consumer service (ACS) URL where the IdP sends its response, and the certificate used to verify the IdP’s signature. Getting these details to match exactly between WordPress and the IdP is most of what setup actually involves; a small mismatch here is the most common source of a SAML integration that almost works.
Mapping IdP groups and claims to WordPress roles
An IdP assertion typically carries more than identity, it can carry group membership or custom claims, and mapping those to WordPress roles is what makes SSO actually useful for access control, not just login convenience. A user in an “Editors” group in the IdP should land in WordPress with editor capabilities, automatically, without an admin manually assigning a role after every new hire. This mapping logic is exactly where a generic plugin’s defaults often fall short of what an enterprise actually needs: multiple IdPs, custom claim structures, or role logic that doesn’t fit a simple one-to-one group mapping.
Where plugins end and custom begins
Off-the-shelf SAML plugins handle a single IdP with a standard claim structure well, and for many organizations that’s genuinely enough. Custom work becomes necessary once you need more than one IdP connected at once, claim mapping that doesn’t fit the plugin’s assumptions, automatic provisioning tied to business logic beyond a simple role match, or SSO that needs to extend beyond WordPress itself into other connected applications.
See single sign-on across connected apps for what that extended pattern looks like, or OAuth 2.0 and OpenID Connect if your IdP speaks a more modern protocol than SAML.
Talk to 84EM about a custom SAML integration if your enterprise SSO needs exceed what a stock plugin maps.
