Single Sign-On (SSO)
Single sign-on lets members sign in with an identity they already have instead of a password stored on your site. Two kinds of identity sources are supported. OpenID Connect providers cover corporate and institutional identity: Google Workspace, Azure AD/Entra, Okta, Auth0, Keycloak, or any compliant Identity Provider. OAuth2 social providers cover consumer identity: Facebook and X today.
With providers configured you get sign-in buttons on the standard login page, on the front-end login form, on WooCommerce's login form, and anywhere else you place the [memb_sso_login] shortcode. Members can connect and disconnect provider identities from their own account page through [memb_sso_connect]. Rules can require specific members to sign in through a provider, refusing their local password and every other login path. And a sign-in can either bind to an existing WordPress account or, per provider, create one on first use.
Who it is for
Federated identity. Your members already have accounts in a corporate directory or platform. Password management moves there, your site trusts its assertions, and offboarding there closes access here.
Social sign-in. A friction-free Facebook or X button converts better than a registration form on consumer-facing sites.
Login policy. Compliance or security requirements that certain populations, staff, contractors, paid tiers, must authenticate through a managed identity source. That is what enforcement is for.
If your site's only login need is a WordPress password, skip this module. It is inert until enabled, and with no provider stored it refuses to block anyone no matter how the settings read.
How a sign-in works
The member clicks a button. Your site sends them to the provider's authorize endpoint with a one-time state value. The provider authenticates them and redirects back with an authorization code. Your site exchanges the code server-side: for OIDC, the identity token is a JWT whose signature is checked against the provider's published keys, along with its issuer, audience, expiry, and nonce; for social providers, the code is exchanged for an access token and the profile is read from the userinfo endpoint. Your site never sees the member's provider password.
The verified claims resolve to a WordPress account. The provider's subject identifier does the binding: one provider identity maps to one account, permanently, across email changes. Email is only a fallback, and only when the provider has verified it and it matches exactly one account. Creating brand-new accounts on first sign-in is a per-provider opt-in, because membership sites usually provision from their CRM rather than from social sign-ups.
When something fails, a provider is unreachable, a token doesn't verify, a claim doesn't resolve, the member lands on a plain error screen saying what failed in one sentence. Nobody gets half logged in: no cookie is set unless every check passed. Every SSO login, linking change, and connection test is written to the event log with member, IP, and provider.
Articles
Rules that make specific members sign in through their provider, applied at every login path WordPress has.
SSO ProvidersAdd and maintain identity provider connections: OIDC directories, social OAuth2 apps, provisioning, and the built-in test tools.
SSO SettingsThe module's settings screen: button visibility, verification rules, social provider gating, and the reference Identity Provider.
Shortcodes
| Shortcode | What it does |
|---|---|
| [memb_sso_connect] | Lets a signed-in member connect or disconnect SSO provider identities. |
| [memb_sso_login] | Renders a sign-in button for each configured SSO provider. |