Handoff Laravel Package

Product Decisions This Supports

• Cross-domain and cross-device authentication UX. clarkewing/handoff lets one Laravel app issue a signed handoff that another app (or another domain/brand surface) redeems to establish a session. v0.2.0 keeps that core intact while tightening where the redemption endpoint can live.
• Guest-to-authenticated conversion funnels (new in v0.2.0). The new guest login flow means a handoff can now establish an anonymous session, not just an authenticated one. This unlocks decisions around: handing off an anonymous cart or basket between storefront and checkout domains, carrying a lead-capture or trial-preview session across surfaces, and deferring account creation until later in the funnel. Scope this as a measurable conversion lever rather than a pure infrastructure item — instrument guest-handoff → registration rate before and after.
• Multi-brand / multi-tenant routing decisions. The /handoff domain constraint (new in v0.2.0) allows scoping the handoff route to a specific host. This is the difference between "one handoff endpoint per app" and "handoff works cleanly across a brand portfolio." Factor it into decisions about consolidating multiple domains onto a single Laravel codebase versus deploying per-brand instances.
• Build vs. buy. The addressable scope is narrow (issue token → redirect → redeem → session). If your roadmap only needs a one-off "log me in over there" link, a weekend of in-house work with Laravel's signed URLs is competitive. If you need the guest variant, domain scoping, and replay/expiry semantics maintained over time, the package is cheap insurance.
• Roadmap signal, not a feature commitment. This is a 0.x package with a small release surface. Treat v0.2.0 as evidence the maintainer is actively addressing real-world multi-domain cases, not as a vendor SLA. Plan for the possibility of a breaking 0.3.0.

When to Consider This Package

Adopt when:

• You operate two or more Laravel-backed domains and users experience a visible "log in again" break at the boundary (marketing site → app, storefront → checkout, regional domains).
• You need session continuity for anonymous users — v0.2.0's guest login flow is the specific reason to look now; before this release the package only solved the authenticated case.
• You want a small, auditable auth mechanism rather than adopting a full SSO/IdP (OAuth server, SAML, Auth0/WorkOS). Handoff is a link-and-session primitive, not an identity provider.
• You are comfortable pinning to an exact 0.x version and re-testing on upgrades.

Look elsewhere when:

• You need true SSO across non-Laravel services, mobile native apps, or third-party SaaS. Use OIDC/SAML against a real IdP.
• You require hardened, audited, 1.0-stable dependencies for a regulated or high-traffic auth path. A pre-1.0 package with a single maintainer is a supply-chain and maintenance risk on your login flow.
• You need fine-grained authorization or role propagation across apps — handoff moves a session, it does not move entitlements.
• Your domains are actually subdomains of one registrable domain — Laravel's native session cookie domain config solves this with zero new dependencies and no redirect step. This is the most common case; check it first before adding a package.

How to Pitch It (Stakeholders)

For executives (one line): A small, actively maintained Laravel component that removes the "please log in again" drop-off when customers move between our domains — and as of v0.2.0 it also carries not-yet-registered visitors across that boundary, so we can defer account creation without losing the session.

For engineering: clarkewing/handoff v0.2.0. Signed, time-boxed session handoff between Laravel apps via a redirect + redeem flow. Two changes this release: (1) a guest login flow — the handoff can now mint an anonymous session, and (2) a /handoff domain constraint — the redemption route can be bound to a specific host, which closes an obvious cross-domain token-replay surface in multi-brand deployments. Both are additive; no deprecations noted in the changelog.

Risks to state plainly:

• Pre-1.0 semver. 0.2.0 is a minor bump, which under semver permits breaking changes. Pin exactly ("clarkewing/handoff": "0.2.0"), and require a changelog review before any bump.
• Thin release surface. "Add guest login flow and domain constraint" is a one-line changelog for two behaviorally significant changes. We should validate the guest path and the constrained-domain path ourselves — the changelog does not describe token TTL, single-use enforcement, or how a guest handoff interacts with an existing authenticated session. Read the source before trusting it on a login path.
• Maintainer concentration. Single-author package. Acceptable for a convenience layer; not acceptable as the sole auth mechanism for a revenue-critical funnel without a fallback path (standard login form still works).

Recommended next step: a one-sprint spike on the guest handoff between two non-production domains, with explicit checks on token expiry, reuse, and authenticated-session collision — plus a written go/no-go against native cookie-domain config as the cheaper alternative.