SSO Enforcement

Enforcement is one promise: this member authenticates through their provider. The module keeps that promise at every door a WordPress login can walk through, not just the password form. A refused member who tries a magic link, a passkey, or their long-lived RSS feed credentials hits the same wall, because each path consults the same policy check. Closing one door never leaves another open.

Enforcement lives on the SSO Settings screen, in three modes.

Off (SSO optional)

Buttons work, linking works, and every other login method keeps working. This is the default, and the right mode while you roll providers out.

Rules (matched members must use SSO)

The Enforcement Rules box, in advanced mode, holds rows. Each row matches a population and names the provider those members must use. A population is an email domain, a role, or a membership level; combine several on one row to narrow it.

The first matching rule wins. A member no rule matches keeps every login method, so you can require SSO for staff while members keep passwords. Rules that name a deleted provider are skipped rather than honored, so removing a provider never locks out the members it covered.

Sitewide (everyone except admins)

All logins go through the Sitewide Default Provider, falling back to your first configured provider when none is named. Administrators always keep local access, and logout still works, so a misconfiguration cannot lock you out of your own site. This is the mode for sites whose members should never see a password form at all.

Strict Provider Enforcement

Off by default. When on, a member whose rule names Provider A is also refused when they sign in through Provider B. Leave it off if members legitimately hold identities at more than one of your providers.

What a blocked member sees

A password attempt is refused with a message pointing them to their provider, on wp-login.php, on the front-end login form, and on every other login path. The message tells them what happened and where to go; it never carries raw provider data.

Boundaries on the promise

Administrators are never bound. Checkout auto-login flows are purchase mechanics, not credential choices, and are exempt. And with no provider configured, the whole system is inert: enforcement refuses to block anyone, whatever the mode says, because a rule you cannot satisfy is just an outage.