Laravel Sanctum + WordPress SSO agency: one login without fake “headless hope”

Product wants a Laravel API and admin. Marketing wants WordPress for content and SEO. Users want one login. Someone suggests sharing cookies across domains and shipping tomorrow. That is how session fixation and support nightmares start. A Laravel Sanctum WordPress SSO agency engagement designs identity boundaries that Sanctum can actually enforce — personal access tokens, SPA cookie auth, or token exchange — without pretending WordPress is Laravel.

HostHob builds hybrid spines for EU teams. Architecture choices: WordPress Laravel hybrid vs headless, agency delivery WordPress Laravel hybrid API agency Europe, NL Laravel capacity Laravel development Netherlands, rescue when SSO already hurts Laravel application rescue. Proof shape: Laravel API partner portal.

What buyers mean by Sanctum SSO

Sanctum is Laravel’s first-party answer for SPA authentication and API tokens. It is not Magical Cross-CMS SSO. Typical honest patterns:

• Laravel as IdP — users authenticate on Laravel; WordPress verifies a signed assertion or exchanges a one-time code to create a WP session.
• WordPress as marketing-only — logged-in product UX never uses WP cookies; WordPress stays public/content.
• Shared browser SPA — Sanctum cookie auth to Laravel API; WordPress is separate origin with limited SSO via explicit handoff.
• Mobile / partner tokens — Sanctum personal access tokens; WordPress not in the loop.

If someone sells “install a plugin and Sanctum SSO appears,” walk away. Domain, HTTPS, SameSite cookies, and user provisioning are the real work.

When hybrid needs SSO vs when it does not

Many successful hybrids never SSO into WordPress wp-admin. Editors use WordPress; customers use Laravel. That is often correct — see hybrid decisioning in hybrid vs headless. SSO becomes necessary when the same human must comment, download member content, and use the Laravel app without two passwords. Membership-to-CRM sync is adjacent but different — do not conflate HubSpot lifecycle with session design.

Architecture we defend

1. Single source of identity — pick Laravel or an external IdP; WordPress becomes a relying party.
2. Short-lived handoff codes over long-lived shared secrets in URLs.
3. Provisioning rules — roles/capabilities mapped explicitly; no “administrator” because a flag was wrong.
4. Logout propagation — define whether Laravel logout kills WP session and vice versa.
5. Audit logging of handoffs without storing raw tokens in application logs.
6. Separate cookies per host — no fantasy parent-domain cookie sharing across untrusted apps.

Experience Cloud or Salesforce portals may still own partner identity — do not invent a third IdP without need; coordinate with Experience Cloud portal patterns when CRM is already IdP.

Delivery checklist

1. Identity source-of-truth decision signed by product and security.
2. Threat model: token theft, open redirect on return URL, privilege escalation.
3. Staging SSO across both hosts with logout matrix tested.
4. Provisioning and deprovisioning (leaver) rehearsal.
5. Monitoring for handoff failure rates.
6. Runbook for key rotation and emergency disable.

When not to hire us

Do not hire us to put every page into a headless WordPress rebuild when a hybrid brochure + Laravel app is enough. Do not hire us for pure WordPress membership passwords with no Laravel. Do not hire us if security will not allow redirect allowlists. Hire us when hybrid delivery is real and SSO is blocking launch — or when a previous agency left half-shared cookies in production and you need rescue.

Failure modes

• Return URL open redirect sends tokens to attacker-controlled hosts.
• WP user created on every handoff without stable external ID → duplicate accounts.
• Sanctum SPA auth misconfigured CSRF; “fix” by disabling protections.
• Editors break when SSO forces their wp-admin through customer IdP.
• Mobile app tokens reused in WordPress contexts they were never meant for.

Ops and EU procurement

Questionnaires ask where sessions live, how long, and who can impersonate. We document Sanctum token TTLs, refresh strategy, and admin impersonation controls. Hosting both apps in EU regions keeps the story coherent with CRM residency programmes. Broader agency framing: API integration agency Europe, WordPress agency Rotterdam API.

Commercial shape

Cost tracks whether WordPress must be a full relying party, number of roles, existing user migration, and whether an external IdP (Entra, Okta, Keycloak) sits above Laravel. A content-site handoff is a slice; multi-app partner portal SSO is a programme — similar gravity to partner portal case.

Bring: domain map, current auth libraries, user role list, and whether wp-admin must SSO. We return a boundary diagram and a phased plan — one login for users who need it, without forcing Sanctum theatre onto a brochure site that should stay logged out.

Migrating existing WordPress users into Laravel identity

Brownfield sites already have thousands of wp_users rows with weak passwords and duplicate emails. SSO programmes fail when they ignore migration: password reset waves, email verification, and linking by stable external ID. We prefer an explicit link table — WordPress user ID ↔ Laravel user ID — created during a controlled migration window, with conflict reports for duplicate emails. Silent “create Laravel user on first SSO” without dedupe recreates the dual-account problem you hired us to end.

Editors and customers should not share the same SSO policy if editors need wp-admin during incidents while IdP is down. Break-glass local accounts with hardware 2FA and monitored use are healthier than forcing every administrator through a customer login path. Document who may use break-glass and how often it is audited.

SPA frontends on a third subdomain add CORS and cookie complexity. Sanctum’s SPA auth assumes careful stateful domains; WordPress handoff should remain a deliberate redirect with allowlisted return URLs, not an iframe that steals cookies. Mobile apps should use token auth to Laravel only; do not stuff Sanctum tokens into WordPress cookies.

Compliance questionnaires will ask about session revocation on password change, role change, and employee exit. We implement revocation lists or versioned session stamps so a fired contractor cannot keep a WordPress cookie alive after Laravel disables them. Pair with CRM entitlement where membership or partner status also gates API scopes — identity without authorisation is only half the story.

If a previous agency left shared Redis sessions or domain-wide cookies across untrusted apps, treat that as an incident-shaped cleanup inside a rescue engagement. We inventory cookies, tokens, and redirect endpoints before adding more SSO surface. Success is fewer password resets, clearer logs, and a threat model your security reviewer signs — not a blog post that says “we use Sanctum.”

Environments, preview sites, and cookie hell

Staging hosts with different parent domains break cookie assumptions that “worked on localhost.” We maintain an environment matrix: production, staging, and preview URLs with explicit Sanctum stateful domains and WordPress handoff allowlists. Developers who add ngrok URLs to production allowlists create open redirect risks; change control must treat allowlists as security config.

Headless frontends on Vercel or similar add another origin. Decide whether that SPA talks only to Laravel (preferred) while WordPress remains content via public APIs without user cookies. Three-way SSO among SPA, Laravel, and WordPress is rarely necessary and often harmful. Hybrid architecture articles on this site exist to push teams toward fewer moving auth parts.

Rate-limit handoff endpoints. SSO endpoints are attractive for credential stuffing against whichever side validates passwords. Logging should capture failure reasons without writing passwords or raw tokens. Alerts on anomalous handoff volume sit beside normal application APM.

Finally, write the user-facing copy: what happens when SSO fails, how to recover, and who to contact. Support macros that say “clear cookies” without distinguishing WordPress versus Laravel cookies waste hours. A small status page during IdP outages beats silent redirect loops. That operational polish is part of an agency SSO delivery — code alone is not the product.

Testing matrix that prevents production surprises

SSO UAT is a matrix, not a single happy path: new user, existing linked user, existing unlinked collision, disabled user, role change mid-session, logout from each side, expired handoff code, reused handoff code, disallowed return URL, and IdP outage. We automate what we can and script the rest for humans. Skipping collision cases is how launch day creates duplicate WordPress users with the same email and different IDs.

Performance under login storms (campaign launches, webinar gates) needs rate limits and caching of JWKS or public keys if using signed assertions. Sanctum token creation should not lock the database harder than your traffic profile allows. Load-test the handoff path before marketing announces “one login.”

Documentation deliverables include sequence diagrams for login and logout, allowlist locations in config, and an emergency “disable SSO, fall back to local auth” switch with known consequences. Agencies that leave only tribal knowledge force you into rescue mode at the worst time — exactly the failure pattern our Laravel rescue work cleans up after.

Related: WP+Laravel hybrid agency · Hybrid vs headless · Laravel NL · Laravel rescue · Partner portal case