Why JWT login breaks in WooCommerce — and how to fix it cleanly

When integrating an external frontend (in my case, an Angular SaaS app) with a WooCommerce webshop,

I hit a surprisingly common wall: JWT authentication just didn’t work across domains.

Cookies were rejected, sessions lost, and SameSite=None turned into a silent killer of cross-domain checkout flows.

Even worse, WordPress refused to authenticate inside an iframe, breaking payment links and embedded logins.

The core issue

WordPress and modern SPAs (Angular, React, Vue, etc.) live in different worlds:

• Different domains
• Different cookie scopes
• Different CORS / SameSite rules

Standard JWT or SSO plugins for WordPress usually fail here because:

1. They rely on wp_set_auth_cookie, which respects SAMEORIGIN by default
2. They don’t allow SameSite=None; Secure cookies
3. They assume same-domain requests

So, even if you send a valid JWT, your SPA can’t establish a native WordPress session cookie.

🔧 The clean fix

I built a small, dependency-free PHP bridge (~200 lines) that safely exchanges a verified JWT for real WordPress cookies,

configured for modern browsers (SameSite=None; Secure; HttpOnly) and protected by a strict CORS whitelist.

👉 GitHub Repository — JWT Login Cookie Bridge

How it works

1. Your SPA obtains a JWT from your backend (or your own auth service)
2. It calls this plugin endpoint (/jwt-login-cookie.php)
3. The plugin verifies the token and sets real WP cookies, as if the user logged in natively
4. Redirects (or iframes) the user back to WooCommerce — now authenticated

✨ Key Features

• Direct JWT → WordPress cookie exchange
• SameSite=None; Secure; HttpOnly compliant
• Strict CORS whitelist for safe cross-domain auth
• Optional iframe embedding (CSP / frame-ancestors)
• Works with WooCommerce sessions and REST API
• No OAuth, no external dependencies — just pure PHP

🚀 Where it helps

• SaaS apps embedding WooCommerce inside external frontends
• Corporate portals running separate SPAs for shop / dashboard
• Projects without server-level access (CSP or X-Frame-Options)
• Any cross-domain WooCommerce ↔ SPA integration scenario

💡 Why this matters

By default, WordPress can’t log users in from external origins.

Standard JWT plugins often break due to SameSite=None restrictions, and OAuth bridges are overkill.

This plugin provides a minimal, production-grade bridge — clean, transparent, and easy to adapt to your setup.

Lessons learned

• SameSite and Secure flags are critical — ignore them and auth silently fails
• Simplicity beats complex SSO frameworks for cross-domain setups
• Sometimes, 200 lines of code can save days of debugging browser cookie logic

If you’ve faced similar SameSite or cross-domain login problems with WooCommerce,

I’d love to hear how you solved them — or whether this approach worked for you.

wordpress #woocommerce #jwt #sso #websecurity #php