Headless WordPress, One Login for Everything

WordPress as a headless CMS sounds simple on paper: keep the familiar editor experience for content teams, expose the content through the REST API, and let a separate application render it however you want. The part that never shows up in the pitch is authentication, especially once WordPress is not the only system your users need to log into.

The problem with two logins

The project I am describing had a Laravel application as the main product and a headless WordPress instance handling marketing pages and blog content. Editors needed to log into WordPress to manage content. The same people, and sometimes the same admins, also needed access to the Laravel side. Two separate logins for one team is a small annoyance at first and a real support burden over time: forgotten passwords, accounts that get out of sync, and no single place to deprovision someone when they leave.

Off-the-shelf SSO plugins exist for WordPress, but most of them assume you are federating with a big identity provider like Google or Okta. We did not want a third-party dependency for something this core, and we already had a working authentication system in Laravel. What we actually needed was for WordPress to trust Laravel’s session, not the other way around.

What we built

The shape of it was straightforward once we stopped trying to force a generic plugin to do something it was not designed for:

• A custom WordPress plugin that, on login, checks for a signed token issued by the Laravel application instead of (or in addition to) a WordPress password
• Laravel issues that token after its own authentication succeeds, signed with a shared secret and short-lived
• The plugin verifies the signature and expiry, then maps the token’s user identity to a WordPress user, creating one on first login if needed
• Logout on either side clears the session on both, so there is no stale half-logged-in state

None of this is exotic cryptography. It is the same signed-token pattern you would use for any service-to-service trust relationship, applied to a CMS that was not really built with this in mind.

Where it got annoying

WordPress’s plugin hooks are not always documented for the exact thing you are trying to override, so a fair amount of time went into reading WordPress core source to find the right filter to hook into for skipping the default login form. The other recurring headache was keeping the plugin working across WordPress core updates, since a filter that behaves one way in one version can shift behavior in the next without much warning in the changelog.

If you are integrating headless WordPress into a larger application with its own auth, my honest recommendation is to treat the SSO layer as a small, boring service-to-service integration rather than reaching for a heavyweight identity provider. It is less flexible than a full IdP, but for a fixed set of internal editors, it does not need to be.