0+
May 19, 2026
April 27, 2026
Integration with WorkOS connects your WordPress site with WorkOS for enterprise-grade identity management.
[workos:login]), and a dedicated /workos/login/{profile} route./members, /team/login) on top of the canonical /workos/login/{profile} rewrite. When the default profile owns a custom path, /wp-login.php 302s to it (preserving every inbound query arg). Reserved core paths can’t be claimed.forward_query_args per-profile toggle — opt-in passing of marketing/analytics query args (utm_*, ref, etc.) onto the post-login destination. WP and plugin internals are always stripped.mfa.enforce (never/if_required/always) and factor allowlist are applied at login time.default falls back to the Site Icon then a bundled WP logo, custom uses the chosen image, none hides the logo).WORKOS_RADAR_SITE_KEY.redirect_to, referrer host, or user role.authenticate filter for custom login forms.?fallback=1 when WorkOS is unavailable.This plugin transmits user data (email, name) to WorkOS for authentication and directory sync. No data is sent until you configure API credentials and users authenticate. API keys are stored in the WordPress database or can be defined as constants in wp-config.php. See the “External services” section for full details on data transmitted.
This plugin connects to the WorkOS API (https://api.workos.com) to provide enterprise identity management features for WordPress.
When a user logs in via WorkOS AuthKit or headless mode, the plugin sends an authorization code (and, in headless mode, the user’s email and password) to WorkOS to exchange for user identity data and access tokens. This happens each time a user authenticates through WorkOS.
When the site administrator creates, updates, or syncs users between WordPress and WorkOS, the plugin sends user profile data (email, first name, last name) to the WorkOS API.
The plugin receives incoming webhook requests from WorkOS containing directory and user data for automatic provisioning and deprovisioning. The webhook endpoint URL is registered with WorkOS by the site administrator.
When managing organizations, the plugin sends and retrieves organization data (name, membership details, role assignments) to and from the WorkOS API.
When audit logging is enabled, the plugin sends WordPress event data (action performed, actor, target, and metadata) to the WorkOS Audit Logs API on each tracked event.
When REST API authentication is enabled, the plugin fetches JSON Web Key Sets (JWKS) from WorkOS (https://api.workos.com/sso/jwks/{client_id}) to verify access tokens. The JWKS response is cached locally for one hour.
WorkOS is provided by WorkOS, Inc.
Sign up at workos.com and find your API Key and Client ID in the dashboard.
Yes, if “Password Fallback” is enabled in settings. Users can access the standard login form via ?fallback=1.
Add the “WorkOS Login” Gutenberg block or use the “WorkOS Login” classic widget. Both render a styled login button that redirects to WorkOS AuthKit.
Use [workos:login profile="your-profile-slug"] or link to /workos/login/{profile}. Both mount the same React shell. The reserved default Login Profile automatically takes over wp-login.php.
Yes. Each Login Profile (WorkOS Login Profiles) picks its own set of enabled methods (password, magic code, any subset of social providers, passkey), pins an organization, and sets its own MFA policy and branding. Reference a profile by slug in the shortcode or URL.
Yes. Edit any profile and tick Use a custom URL path, then fill in the path (e.g. members or team/login). The plugin registers an extra rewrite rule that mounts the same React shell at https://yoursite.com/members/. The canonical /workos/login/{slug} URL keeps working too. Reserved core paths (wp-admin, wp-includes, wp-content, wp-json, workos, feed, etc.) are blocked at save time. If you set a custom path on the default profile, /wp-login.php?action=login 302s to it for everyone (with all redirect_to / interim-login / language / nonce args preserved).
Users can bypass the WorkOS redirect by appending ?fallback=1 to the login URL (e.g., wp-login.php?fallback=1). This loads the standard WordPress login form with native password authentication.
Yes. The Entitlement Gate feature restricts login to users who belong to the configured WorkOS organization. Users without a membership are denied access with a customizable error message.
Use the Onboarding Wizard (Settings > WorkOS > Onboarding) for a guided walkthrough, or use the WP-CLI command wp workos sync push to bulk-push users to WorkOS.
Yes. Organizations can be mapped to specific sites in a multisite network, and the plugin stores organization-to-site mappings in a dedicated table.
Go to Tools > WorkOS Diagnostics in the WordPress admin. The diagnostics page checks API connectivity, configuration completeness, database schema status, and other health indicators.
manage_options. No bulk re-enable yet — WorkOS does not expose a public REST endpoint for the “Re-enable email” action. (CONS-273)edit_user capability on a linked target (which includes self-service, since WP grants edit_user on one’s own ID) can send a WorkOS reset email via three surfaces — a row action on wp-admin/users.php, a “Password Reset” panel on the user-edit screen, and the new [workos:password-reset] shortcode. The shortcode supports both admin-of-other (user="…") and self-service (no user attr) modes. (#21)redirect_url parameter on the admin REST endpoint and on the existing public reset endpoints. The value is validated against home_url() host, threaded through the WorkOS-hosted email link, and used by the AuthKit React shell to send the user to the chosen page after a successful reset. Fixes the CONS-287 regression where the post-reset URL was unconfigurable./workos/login/{slug}?token=…&redirect_to=…) instead of wp-login.php. The old wp-login.php?workos_action=reset-password URL still resolves cleanly so any reset emails already in users’ inboxes keep working.wp.passwordStrength.meter (zxcvbn) and the submit button stays disabled until the fields match and the score reaches Strong. Site name and common words are passed as the zxcvbn disallowed list.auto_login_after_reset toggle (default on). When enabled, a successful password reset signs the user in (via the shared LoginCompleter, so MFA / organization selection / entitlement gates still apply) and lands them on the validated post-reset redirect URL. With the toggle off the user lands on the existing “Password reset — Continue to sign in” card.wp_set_password() so the WP password fallback (?fallback=1, wp_authenticate, REST app passwords) stays in sync with the WorkOS password the user just typed. Unlinked users no-op cleanly./workos/login/{profile}, and the shortcode) paint a card-shaped silhouette with shimmering rows the moment the page lands, instead of a blank gap while the React bundle downloads and bootstraps. Heights match the hydrated form one-to-one so the swap is a flicker, not a layout jump. Honours prefers-reduced-motion.wp-login.php?loggedout=true is now claimed by the AuthKit takeover instead of rendering native wp-login. The “you have been logged out” screen advertised the wp-login username/password field, which legacy customers misread as a still-working classic sign-in. The URL now 302s to /login/?loggedout=true (or the configured custom path) so the React form handles it. ?fallback=1, ?workos=0, and action=logout|lostpassword|rp|... bypasses are unchanged. (#18)?workos_action=…&profile=…&token=…) when a home_url/login_url filter on the host ran the URL through esc_url(). The plugin now decodes HTML entities in build_password_reset_url() before posting to WorkOS so the emailed link is valid. (#17)Cache-Control: no-store / Pragma: no-cache headers on auth redirects so cached responses do not trap the browser in a redirect cycle when returning to a previously visited URL. (#15)update_profile‘s array_replace_recursive($existing, $params) merge preserved trailing entries from the existing list when the incoming list was shorter, so removed methods reappeared after save. The REST update now explicitly overwrites methods and mfa.factors from the payload (using array_key_exists() so an empty array is honored). Other scalar/associative fields are unaffected. (#14)organization_selection_required. When the Login Profile has an organization pinned (with Config::get_organization_id() as a fallback), the plugin re-authenticates via the organization-selection grant instead of surfacing “The user must choose an organization to finish their authentication.” to the user.user_id. Membership creation and the entity_already_exists short-circuit are logged via workos_log() (visible under WP_DEBUG / WORKOS_DEBUG). Strangers and ambiguous lookups still get a clean pinned_org_mismatch error — no email-lookup guessing./workos/callback now routes through LoginCompleter, so it shares the same organization_selection_required recovery, MFA gating, and post-login bookkeeping as the AuthKit REST endpoints. The callback no longer short-circuits on the WorkOS error and discards the OAuth code. Legacy AuthKit-redirect callbacks (no profile slug in state) keep their original redirect contract — the state-supplied redirect_to still wins over the default profile’s post_login_redirect.wp_authenticate() to cover users whose passwords were never synced to WorkOS, then link the user to WorkOS and (by default) write the password through so future logins authenticate directly. A new “Require Email Confirmation on Fallback” setting switches the post-fallback step to a magic-code email instead of syncing the plaintext password. Gated by the existing allow_password_fallback toggle.WORKOS_* (or env-scoped WORKOS_{PRODUCTION|STAGING}_*) constants now seeds those values into the database on boot, so the admin UI reflects them. Covers string credentials, the new boolean toggles, and WORKOS_REDIRECT_URLS arrays. Hash-skipped when nothing has changed — one autoloaded option read per request in steady state./wp-json/workos/v1/auth/* now read the nonce from X-WorkOS-Nonce instead of X-WP-Nonce to avoid a header collision with WordPress core and other plugins. The bundled React shell is updated; external clients hitting these endpoints directly must rename the header.?refresh=1 query parameter on GET /wp-json/workos/v1/admin/profiles/organizations to drop the shared transient before fetching.org_name input. The Create Organization modal is now rendered at admin_footer so its inner <form> is no longer nested inside the settings form.workos_active_environment while the runtime auth flow read from workos_global['active_environment'], so picking “Production” still loaded staging credentials and redirected to the staging AuthKit. The runtime now reads/writes the standalone option, with a one-time migration (db_version 2 3) that moves any legacy value out of workos_global.Custom AuthKit (WordPress-hosted login):
* React login shell on wp-login.php, [workos:login] shortcode, and /workos/login/{profile} route.
* Login Profiles — admin-defined presets for enabled methods, pinned organization, signup/invite/reset flows, MFA policy, and branding, managed at WorkOS Login Profiles.
* Per-profile custom URL paths (e.g. /members, /team/login) on top of the canonical /workos/login/{slug} rewrite. The default profile can claim a custom path so /wp-login.php bounces to it. Reserved core paths are blocked.
* Already-signed-in visitors are 302’d to their post-login destination on every AuthKit surface (or shown an inline “You’re already signed in” notice in the shortcode).
* Per-profile forward_query_args toggle to pass marketing/analytics args onto the post-login destination (internals always stripped).
* Pinned-organization picker in the Profile editor reads live from WorkOS (with a “Custom ID…” fallback for legacy or unlisted orgs), and the Profiles list renders organization names instead of raw IDs.
* Embed & URLs section in the editor exposes copyable input fields for the canonical URL, the optional custom-path URL, and the [workos:login profile="…"] shortcode.
* Sign-in methods: email + password, magic code, social OAuth (Google, Microsoft, GitHub, Apple), passkey.
* Full MFA support — TOTP, SMS, WebAuthn/passkey with in-app enrollment + challenge.
* Self-serve sign-up, invitation acceptance, and in-app password reset.
* Branding — heading, subheading, primary color (defaults to WordPress admin-color palette), and three-mode logo control (default falls back to Site Icon bundled WP logo, custom uses the chosen attachment, none hides the logo).
* SlotFill extensibility — ten named slots (including workos.authkit.belowCard, which renders standard wp-login.php links by default) for plugins to inject React elements into the login UI.
* Profile routing rules (redirect_to glob / referrer host / user role).
* WorkOS Radar anti-fraud integration (set WORKOS_RADAR_SITE_KEY).
* Public REST at /wp-json/workos/v1/auth/* with profile-scoped nonces, per-IP/per-email rate limits, and signature-verified tokens.
* Full browser internationalization — every user-facing React/TS/JS string ships through @wordpress/i18n with the integration-workos text domain and wp_set_script_translations() wiring.
Base platform:
* SSO login via WorkOS AuthKit (legacy redirect mode, per-profile selectable).
* Headless authentication via WorkOS API.
* Directory Sync (SCIM) for automatic user provisioning and deprovisioning.
* Role mapping between WorkOS organization roles and WordPress roles.
* Organization management with local caching and multisite support.
* Entitlement gate — require organization membership to log in.
* Webhook processing for user, organization, directory, membership, and connection events.
* REST API Bearer token authentication using WorkOS access tokens.
* Legacy login button Gutenberg block and classic widget (AuthKit-redirect flow).
* Login bypass via ?fallback=1 for native WordPress login when WorkOS is unavailable.
* Activity logging with local database table and admin viewer.
* Audit logging — forward WordPress events to WorkOS Audit Logs.
* Role-based login redirects with per-role URL configuration.
* Role-based logout redirects with per-role URL configuration.
* Password reset integration with WorkOS.
* Registration redirect to WorkOS AuthKit.
* Admin bar badge showing active environment (production/staging).
* Diagnostics page with health checks and connectivity tests.
* Onboarding wizard for guided first-time setup.
* WP-CLI commands for status, user management, organization management, and bulk sync.