Laravel Sso Client Laravel Package

Product Decisions This Supports

• Enterprise / B2B readiness gating. Federated logout is a checkbox item on most enterprise security reviews and vendor questionnaires (SOC 2, ISO 27001, "does logging out of your app terminate the IdP session?"). This release converts an open item into a shipped capability, which directly affects whether the product can clear procurement for larger accounts.
• Build vs. buy on identity. This package lets the team not build SSO session management. The decision it supports is narrow and deliberate: adopt laravel-sso-server as the identity provider and this package as the client, rather than standing up a generic OIDC/SAML integration. Worth pricing against the cost of a bespoke integration plus ongoing security maintenance.
• Roadmap sequencing for the identity track. With authentication and now session termination handled, the natural next bets are provisioning/deprovisioning (SCIM), directory sync, and admin-visible session/audit data. This release closes the "logout" chapter and frees sequencing room for those.
• Shared-device and kiosk use cases. Full SSO session termination on logout is the difference between "acceptable for a shared workstation" and "not acceptable." If kiosk, clinic, factory-floor, or lab scenarios are on the roadmap, this unblocks them.
• Account-linking risk posture. The email_verified enforcement change is a security decision, not a feature: linking a local account to an SSO identity by email is an account-takeover vector if the IdP will assert unverified addresses. The new behavior defaults safely and preserves 1.0 behavior for servers that don't send the claim — so it's an upgrade you can ship without a security review cycle, but you should still document the policy for customers who control their own IdP.
• Multi-app portfolio coherence. If the org runs several first-party Laravel apps, "log out of one, you're out of all" is a UX and support-cost decision. This makes the fleet behave like one product rather than N products sharing a login.
• Support-cost reduction. Fewer "I logged out but my colleague's browser still had me signed in" and fewer stale-session tickets after offboarding.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel/PHP and already use (or have decided to use) laravel-sso-server 1.1+ as the identity provider. This is a paired client for a specific server package, not a generic OIDC/SAML client — that coupling is the single biggest adoption criterion.
• You have two or more first-party applications behind one login, where cross-app session termination is meaningful. With one app, federated logout is mostly a nicety.
• Enterprise buyers, security questionnaires, or regulated environments are on the near-term revenue path and "logout ends the SSO session" is being asked for.
• Shared-device, kiosk, or contractor/offboarding scenarios exist where a lingering IdP session is a real risk.
• You want the email-based account linking guardrail — i.e., you're linking pre-existing local accounts to SSO identities and want a defensible default rather than a custom rule.
• Your team would rather consume a maintained integration than own session/logout semantics, CSRF handling, and token storage themselves.

Look elsewhere when:

• You need SAML, generic OIDC, social login, or multi-IdP support. This is a client for one server implementation; it won't broker identities from Okta/Entra/Auth0 without that server in front.
• You need SCIM provisioning or directory sync — not in scope here.
• You're on a non-Laravel stack, or pinned to an older Laravel/PHP line that isn't the tested matrix (PHP 8.4 / Laravel 13 with SQLite, MySQL, PostgreSQL).
• Single-app products without enterprise pressure — the upgrade is low-cost but the value is near zero; don't spend the release slot on it.
• You require fully server-side session revocation semantics you control, e.g., an admin "force logout all users" console. Federated logout is user-initiated; that's a different capability.

Migration cost to flag in planning: the upgrade requires adding 'logout' => '/sso/logout' to endpoints and post_logout_redirect_uri in published configs, and changing logout buttons from GET/links to a POST to sso-client.logout. There's a known transitional edge case: users who signed in before the upgrade have no stored token and will be logged out locally only — plan release notes so support isn't surprised. Also note SSO_POST_LOGOUT_REDIRECT_URI must be same-origin as the redirect URI, which constrains where you can land users post-logout (marketing site vs. app).

How to Pitch It (Stakeholders)

For executives: We get enterprise-grade "log out everywhere" behavior without building it. When a user signs out, the identity provider ends the session and signs them out of every connected app — the thing security reviewers ask about in procurement. It also closes an account-takeover gap by only linking existing accounts to SSO when the identity provider has actually verified the email address. Cost is a small, well-understood upgrade: one config entry and a logout-button change, tested against PHP 8.4 / Laravel 13 on all three major databases, including interop tests against the server. Framed commercially: this removes a recurring blocker in enterprise deals and shared-device deployments, and it's the last major gap before we can talk credibly about provisioning as the next identity investment.

For engineering: Small surface area, safe defaults, no forced breaking change. email_verified enforcement only tightens behavior when the server sends the claim — servers that don't send it retain 1.0 behavior, so it's opt-in in practice. Federated logout is a CSRF-protected POST route; the work is (a) add the two config keys if you've published the config, (b) switch logout UI from links to form POSTs, (c) confirm the post-logout redirect URI is same-origin. Pre-upgrade sessions degrade gracefully to local-only logout rather than erroring. There are also Boost guidelines and a sso-client-development skill shipped in resources/boost to speed agent-assisted work on this integration.