SSO Providers

The Providers screen is where identity provider connections live. Each row is one provider: a label your members will recognize, the credentials your IdP issued for this site, and the decisions about what happens when one of its identities signs in. Rows can be edited, duplicated, and removed from the list.

Open the screen from the Control Center card labeled SSO Providers.

Adding an OIDC provider

Choose the OIDC type and fill in four things: a Label, the Issuer URL from your IdP's discovery document (the base URL, like https://login.example.com), and the Client ID and Client Secret your IdP issued for this site. The authorize, token, userinfo, and signing key endpoints are discovered automatically from the issuer. If your IdP's discovery document is missing or wrong, endpoint overrides are available in advanced mode.

Adding a social provider

Turn on Enable OAuth2 Providers on the SSO Settings screen first; until then social providers are stored but their buttons never render. Then supply the authorize, token, and userinfo endpoint URLs from the platform's documentation for developers, plus your app's Client ID and Secret. Facebook and X are the tested shapes; any OAuth2 provider that documents those three endpoints will work.

Fields common to both

The client secret deserves its own note. It is encrypted at rest, per provider, and never rendered back to the browser. On edit, leave the field blank to keep the stored secret.

Duplicating a provider row carries the secret over, re-encrypted under the copy's own context, and appends "(Copy)" to the label. Useful for staging a variant of a working provider before you modify the original.

Provisioning

Per provider, you decide what a sign-in resolves to:

Match is the default. The sign-in is bound to an existing WordPress account, found through the subject identifier, or through a verified email that matches exactly one account.

JIT create builds the account on first sign-in. You choose the default role, tags to assign on creation, and an optional email-domain allowlist; sign-ins from domains outside the allowlist are refused. Roles with administrative capabilities are never created through JIT, whatever the role field says.

Membership sites that provision from their CRM usually want Match. JIT fits sites whose members arrive through the front door.

Test before you trust

Each provider row has a Test Connection action. It checks discovery, signing keys or endpoint reachability, and that the authorize URL builds from your stored configuration. Results land in the event log with a pass or fail notice on screen.

For an end-to-end rehearsal without a real IdP, the module ships a Reference OP: a minimal built-in Identity Provider on the settings screen. It answers only requests from trusted IPs and expects a fixed client, so it cannot be exposed accidentally. Configure a provider against it, sign in, watch the whole handshake, then point the provider at your real IdP.