Laravel Jetstream Passport Laravel Package

Product Decisions This Supports

• OAuth2 / API access strategy: This package wires Laravel Passport (OAuth2 server) into a Jetstream application, so it directly supports decisions about exposing a public or partner API, issuing tokens to first-party mobile/SPA clients, and offering "Sign in with [Product]" style integrations.
• Consent & authorization UX (the v1.0.2 delta): The new authorize view makes the OAuth consent/authorization screen a first-class, customizable artifact. That unlocks product decisions around branded consent screens, scope disclosure, legal/compliance copy (GDPR-style consent, third-party data access notices), and trust-building at the moment a user grants access to their account.
• Build vs. buy for identity: Provides a credible "build on our own stack" option versus Auth0/Okta/WorkOS/Descope. Because it sits on Laravel's own Passport and Jetstream, it avoids vendor spend and keeps user data in-house — relevant when procurement, data residency, or per-MAU pricing is a factor.
• Multi-tenant / team-scoped access: Jetstream's teams model plus Passport tokens supports B2B decisions like per-workspace API credentials, partner integrations scoped to a team, and admin-managed client applications.
• Roadmap sequencing: Useful for teams already on Jetstream who want to ship integrations and mobile clients without standing up a separate identity service. The authorize-view addition lowers the effort of shipping a presentable consent flow, so "partner API access" can move earlier on a roadmap.
• Scope clarification: This is an OAuth2 provider concern, not social login. Decisions about "Login with Google/GitHub" belong to Socialite; keeping those conversations separate avoids conflating two different roadmap items.

When to Consider This Package

Consider it when:

• You are already running Laravel with Jetstream and Passport, and want the authorization/consent screen integrated rather than hand-rolling blade views against Passport internals.
• You need an OAuth2 authorization server for first-party clients (mobile, SPA) or a modest number of third-party/partner integrations, and you want to own it rather than pay a vendor.
• You want a customizable consent screen for branding or legal review — the newly added authorize view is the reason to look now rather than before.
• Your team is small and comfortable owning security patching of an identity component, with a clear upgrade path to raw Passport if the wrapper is abandoned.

Look elsewhere when:

• You need enterprise SSO (SAML, OIDC federation, SCIM provisioning) — this is not that; evaluate WorkOS, Auth0, or Laravel's own SSO offerings.
• You only need first-party API tokens for your own SPA — Sanctum is the simpler, lower-surface-area choice; adding a full OAuth2 server is unnecessary complexity.
• You require managed compliance attestations (SOC 2, ISO 27001), 24/7 support SLAs, or multi-region identity infrastructure.
• You are not on Jetstream, or you have customized auth heavily enough that the package's assumptions fight your architecture.
• Maturity caveat: This is a young package (v1.0.x, small maintainer, sparse release history). Treat it as a dependency to vet, pin, and monitor — check issue responsiveness and security disclosure practices before it becomes load-bearing.

How to Pitch It (Stakeholders)

For executives: This package lets us offer OAuth-based API access and partner integrations — the plumbing behind "connect your account" and mobile app sign-in — on infrastructure we already run, without a new identity vendor contract or per-user fees. The v1.0.2 release adds a customizable authorization screen, which means we can brand the consent step and put reviewed legal language in front of users at the exact moment they grant third-party access. That is a meaningful trust and compliance improvement for near-zero additional engineering cost. Because it is built on Laravel's first-party Passport and Jetstream projects, our exposure is limited: if the wrapper stalls, the underlying capability remains and we can migrate to Passport directly.

For engineering: v1.0.2 is a low-risk, non-breaking increment — a publishable authorization view plus README updates. No migrations, no API changes, no deprecations. Adopt the view via publish-and-own so branding and copy changes do not require forking. Pin the version, review the view for scope display and CSRF/session handling before shipping to production, and keep a documented fallback path to raw Passport. Flag the package's small maintainer base as a tracked dependency risk rather than a blocker.