WordPress SSO with MojoAuth

Connect your WordPress site to MojoAuth using OpenID Connect (OIDC) and the popular community OpenID Connect Generic Client plugin (by daggerhart). MojoAuth acts as the OIDC Provider (OP); WordPress acts as the OIDC Relying Party (client). Once configured, wp-login.php shows a "Login with OpenID Connect" button that redirects users to MojoAuth to authenticate, then signs them into WordPress with a mapped local account.

How it works

Prerequisites

A MojoAuth project (test or live) with admin access to Developers → Applications.
A WordPress site (self-hosted, or a host that allows installing plugins — most managed hosts do, but some locked-down managed platforms restrict plugin installs) with Administrator access.
Ability to install and activate a plugin from Plugins → Add New, or upload it manually if your host blocks the plugin directory.
Decide whether WordPress users will be matched by email or by a username/identifier claim, and whether you want new WordPress accounts created automatically on first login (JIT provisioning).

⚠️

Installing OpenID Connect Generic Client does not remove the normal WordPress username/password login form by default — both appear on wp-login.php unless you explicitly enforce SSO. Keep the standard login form available and test with a non-admin account first, so you don't lock yourself out of wp-admin.

Step 1 — Create the MojoAuth OIDC application

In the MojoAuth dashboard, go to Developers → Applications → New Application → OIDC / OAuth 2.0.
Give it a name (e.g. WordPress – Production) and click Create.
Copy the generated Client ID and Client Secret — the secret is shown once, so store it somewhere safe (you'll paste both into the WordPress plugin in Step 2).
Leave the Allowed Callback URLs field open for now — you'll add WordPress's redirect URI in Step 3, after installing the plugin (it's a fixed, predictable path so you can also add it now).

See OIDC Applications for the full concept walkthrough.

Step 2 — Install and configure the plugin in WordPress

Install the plugin

Go to Plugins → Add New, search for "OpenID Connect Generic Client" (by daggerhart), install it, and click Activate. If your host blocks the plugin directory, download it from the WordPress.org plugins repository and upload the zip under Plugins → Add New → Upload Plugin.

Open the settings screen

Navigate to Settings → OpenID Connect Client. This single screen holds all the client configuration.

Enter the client credentials and scope

Plugin field	Value
Login Type	`OpenID Connect Button on login form` (recommended) or `Auto Login - SSO` to skip the button and redirect straight to MojoAuth
Client ID	`{client_id}` from the MojoAuth OIDC application
Client Secret Key	`{client_secret}` from the MojoAuth OIDC application
OpenID Scope	`openid email profile`

Enter the MojoAuth endpoints

The plugin does not do OIDC discovery — you enter each endpoint explicitly:

Plugin field	Value
Login Endpoint URL	`{BASE}/oauth/authorize`
Userinfo Endpoint URL	`{BASE}/oauth/userinfo`
Token Validation Endpoint URL	`{BASE}/oauth/token`
End Session Endpoint URL	`{BASE}/oauth/logout`

The plugin's field is labeled "Token Validation Endpoint URL" but it's the OIDC token endpoint — point it at {BASE}/oauth/token, the same URL used for the authorization-code exchange.

Set identity, nickname, and email formatting

Lower on the same settings page:

Plugin field	Value
Identity Key	`email` (or `sub` if you prefer matching on the immutable subject identifier)
Nickname Key	`preferred_username`
Email Formatting	`{email}` (leave as the `email` claim passthrough)
Display Name Formatting	`{email}` or `{given_name} {family_name}` if you also map profile claims

Click Save Changes at the bottom of the page.

Step 3 — Add WordPress's redirect URI to MojoAuth

The plugin's callback is a fixed path handled through WordPress's AJAX router, not a page you create:

https://<site>/wp-admin/admin-ajax.php?action=openid-connect-authorize

Copy this URL with your real domain substituted for <site>, go back to the MojoAuth OIDC application, and add it to Allowed Callback URLs exactly as shown (protocol, host, and query string included). Save the application.

⚠️

This URL must match exactly, including https:// vs http://, trailing characters, and the ?action=openid-connect-authorize query string. A mismatch here is the single most common source of login failures with this plugin (see Troubleshooting below).

Step 4 — Claim mapping and user matching

The plugin's settings page has two related controls: "Identity Key" (which claim identifies the user) and, further down, user linking/creation options. Configure both consistently with what MojoAuth sends.

WordPress needs	OIDC scope/claim	Notes
Unique user identifier	`sub` (always returned with `openid` scope)	Use as Identity Key if you don't want identity tied to a mutable email address
Email	`email` (`email` scope)	Most common Identity Key; also populates the WP user's email field
Display name / username seed	`preferred_username` (`profile` scope)	Maps to Nickname Key
First/last name	`given_name`, `family_name` (`profile` scope)	Optional, used in Display Name Formatting

Example: request scope openid email profile, set Identity Key to email, Nickname Key to preferred_username. On first login, the plugin looks up a WordPress user whose email matches the email claim in the MojoAuth ID token/userinfo response.

Below the identity fields, two checkboxes control account handling:

Link Existing Users — when enabled, if a WordPress user already exists with a matching email (or whichever field the Identity Key points to), the plugin logs into that existing account instead of erroring out. Enable this if you're rolling SSO out to a site that already has manually-created accounts.
Create user if does not exist — enables JIT provisioning: a new WordPress user is created automatically on first successful login if no match is found. Leave this unchecked if you want to provision accounts out-of-band and have SSO fail closed for unknown users.
Enforce Privacy (optional) — when enabled, redirects anonymous visitors straight to MojoAuth login instead of showing any public WordPress content, effectively making the whole site SSO-gated.

To add a visible login button anywhere other than wp-login.php (a page, a widget, a theme template), use the shortcode:

[openid_connect_generic_login_button]

Step 5 — Test

Open wp-login.php in a private/incognito window — you should see a "Login with OpenID Connect" button below (or instead of, if Login Type is set to Auto Login) the normal username/password form.
Click it. You should land on MojoAuth's hosted login page at {BASE}.
Authenticate with a MojoAuth test user. You should be redirected back to admin-ajax.php?action=openid-connect-authorize and then into /wp-admin/, signed in as the matched (or newly created) WordPress user.
Check Users → All Users to confirm the account was matched to the right existing user, or created with the expected email/display name if JIT provisioning is on.
If you enabled Auto Login - SSO, visit the site logged out — you should be redirected to MojoAuth immediately with no button click required. Confirm wp-login.php?loggedout=true (or a similar direct login URL) still works as an escape hatch for administrators if the SSO path breaks.

There is no "Test SSO" button on the WordPress side — the button click in Step 1 above is itself the SP-initiated test. Success looks like landing in /wp-admin/ signed in with the right identity; any failure surfaces as a WordPress admin notice or a redirect loop back to wp-login.php.

Troubleshooting

"Login Failed" / redirect_uri mismatch after clicking the login button MojoAuth rejects the callback because the redirect URI the plugin sent doesn't exactly match an entry in Allowed Callback URLs. Re-check Step 3: the URL must be https://<site>/wp-admin/admin-ajax.php?action=openid-connect-authorize, with the correct scheme (https://) and no typos in the domain. If the site is reachable at both www and non-www hosts, add both variants.

User created or matched with the wrong identity ("no matching user" or duplicate accounts) The Identity Key field doesn't correspond to a claim MojoAuth actually returns for your requested scope. If Identity Key is set to email but email isn't in OpenID Scope, no email claim is returned and matching fails. Confirm OpenID Scope includes email (and profile if you use preferred_username/name claims), then re-test.

"Create user if does not exist" is unchecked and legitimate SSO users get "no account" errors This is expected — with JIT provisioning off, only pre-existing WordPress accounts (matched via Identity Key + Link Existing Users) can log in via SSO. Either enable Create user if does not exist for self-service provisioning, or create the WordPress account manually first if you want tighter control over who gets an account.

Blank page, 500 error, or "invalid state" after redirect back from MojoAuth Usually a cookie or nonce problem: the plugin stores a state/nonce value in a transient/cookie before redirecting to MojoAuth, and validates it on the way back. This breaks if the site sits behind a caching layer or CDN that caches the login redirect, if WP_HOME/WP_SITEURL don't match the actual domain used in the callback, or if cookies are blocked by browser privacy settings/a mismatched https/http scheme between the two legs of the flow. Exclude wp-login.php and admin-ajax.php from full-page caching, and confirm the site loads consistently over https:// end to end.

Endpoint fields swapped or left as placeholder values The plugin ships with example endpoints (often generic OAuth provider examples) that must be overwritten entirely — Login, Userinfo, and Token Validation Endpoint URLs are three separate fields, and mixing up the token and userinfo URLs is a common copy-paste mistake. Confirm they read exactly: {BASE}/oauth/authorize, {BASE}/oauth/userinfo, and {BASE}/oauth/token respectively.

Logout doesn't sign the user out of MojoAuth (stays signed in on next login click) Confirm End Session Endpoint URL is set to {BASE}/oauth/logout. Some plugin versions only call this endpoint if a corresponding logout option is enabled on the settings page — check for a "Enable Logout Redirect" or similar toggle near the End Session field.

Locked out of wp-admin after enabling "Enforce Privacy" or Auto Login If SSO breaks after enabling site-wide enforcement, log in directly with https://<site>/wp-login.php?loggedout=true (or disable the plugin via SFTP/File Manager by renaming its folder under wp-content/plugins/) to regain access, fix the configuration, then re-enable enforcement.

SAML alternative

If you'd rather use SAML 2.0 instead of OIDC, WordPress has several community "SAML SSO" plugins (e.g. miniOrange SAML SP, OneLogin SAML SP) that connect to MojoAuth the same way as other SAML service providers: create a SAML connection in MojoAuth, import the plugin's SP metadata (or enter its Entity ID and ACS URL manually), map attributes, and upload MojoAuth's signing certificate on the WordPress side. See SAML SSO Connections for the general SAML setup steps — the click-path inside WordPress differs by plugin but the MojoAuth-side configuration is the same.