Oauth2 Laravel Package

Product Decisions This Supports

• "Do we need to be an OAuth2 provider at all?" This package only makes sense if the product decision is our Laravel app issues tokens to someone else — a public API, a partner/developer platform, a marketplace of third-party apps, or a mobile/desktop client we don't fully control. That is a distinct decision from "our app calls someone else's API" (client side: league/oauth2-client, Socialite) and from "our own SPA calls our own API" (Sanctum). Getting this classification right is the highest-leverage thing a PM does here; the rest is implementation detail.
• Build vs. buy for the authorization server. The realistic shortlist is Laravel Passport (first-party, maintained, built on league/oauth2-server), an external IdP (Auth0, Keycloak, Ory Hydra), or this package. splash/oauth2 is a same-problem alternative to Passport, not a complement — so the PM decision is "which server implementation do we stand behind," and the honest answer at 0 stars / 0 dependents is that this one is reference material, not a candidate.
• Which grant types the product must support. The listed set — authorization code, client credentials, password — maps directly onto product surfaces: authorization code = "Connect your account" consent screens for third parties; client credentials = machine-to-machine/server-to-server API access; password = legacy first-party login. The absence of PKCE in the description is a roadmap flag: PKCE is now the baseline for public clients (mobile, SPA, CLI), so if the roadmap includes any of those, this package's feature set is already behind current OAuth guidance.
• Scoping (permissions) as a product surface. Eloquent-backed scopes plus scope middleware means permission design becomes a customer-facing artifact — consent copy, granularity, least-privilege defaults, and what happens when a scope is revoked. A PM owns that taxonomy; the package only enforces it.
• Deprecating the password grant. Its presence as a headline feature signals a pre-OAuth-2.1 design. If we're issuing tokens for third parties, the PM decision is to ship authorization code (+ PKCE) only and treat password grant as a migration problem, not a feature.
• Security-review budgeting. Token lifetimes, refresh-token rotation, revocation, and secret storage are all product commitments with user-visible failure modes ("reconnect your account" states). This package is a useful checklist of which decisions must be made, even if we never ship it.
• Explicitly not a vendor dependency decision. Zero stars and zero dependents means no adoption signal, no bug reports, no community pressure-testing on exactly the code path (token issuance and validation) where failure is a breach. That absence is itself a product input.

When to Consider This Package

Consider reading it if:

• We are already inside the Splash/SplashTools ecosystem and share its Laravel conventions, so the service provider, config, and Eloquent models drop in without translation.
• We want a small, readable reference implementation of an OAuth2 server in Laravel — the publishable config and migrations make the data model (clients, tokens, scopes) legible in an afternoon, which is genuinely useful for scoping our own design or a Passport rollout.
• We need a throwaway or internal-only token issuer behind a low-value boundary, we can vendor it into our monorepo at a pinned commit, and we have a named owner. Never as a floating Composer dependency from GitLab.
• We want a comparison baseline to pressure-test Passport: if this package's model is materially simpler for our use case, that tells us something about what we actually need.

Look elsewhere when:

• We need production auth. This is a security-critical surface. laravel/passport is the maintained, first-party, community-audited answer to the same problem and should be the default. If we don't want to own an OAuth server at all, an external IdP is the lower-risk buy.
• Our need is first-party API tokens (our SPA, our mobile app, service-to-service within our own boundary). laravel/sanctum is simpler, maintained, and sufficient; running a full authorization server here is over-engineering with a real security cost.
• We need modern protocol features — PKCE, OIDC/ID tokens, device code flow, token introspection/revocation endpoints, key rotation, per-client token encryption at rest. None of these are claimed, and none should be assumed at this maturity.
• We need a supported release cadence. No stars, no dependents, no issue history, almost certainly a single maintainer and a GitLab project that may go read-only without notice.
• We can't get a security review and an owner. An unowned auth server is worse than no abstraction.

How to Pitch It (Stakeholders)

To executives: This package would make our app an OAuth2 authorization server — the thing that issues API tokens to partners and third-party apps. That's a real capability with real strategic weight, but this specific package is a small, unproven, zero-adoption project from a single vendor's toolchain, with no support commitment. Recommendation: treat it as free reference code, not a dependency. We adopt the pattern — authorization-code + PKCE grants, scoped permissions, Eloquent-backed clients and tokens — and build on Laravel Passport or an external identity provider. This avoids putting an unmaintained component directly on top of our customers' credentials, and it avoids a security incident that would cost far more than the days it might save.

To engineering: Read the source, don't ship it. The evaluation is a two-day spike with a hard kill criterion: does it reimplement the grant flows itself or delegate to league/oauth2-server? Is there a license? Does it support PKCE, and does it pin an ancient Laravel/Guzzle version? Review state/nonce handling, redirect URI allowlisting, refresh-token rotation and revocation paths, and whether tokens are encrypted at rest or merely stored. If the answers are good, mirror it internally at a pinned SHA behind our own OAuthServer interface so call sites stay portable. If not — the likely outcome — take Passport as the baseline and this repo as a design checklist for what our implementation must get right.

Decision framing to align on: the deliverable is "a supported, security-reviewed way for third parties to obtain scoped tokens to our API, shipped by date X," not "added a dependency." Passport gets us there with maintenance behind it; splash/oauth2 is how we make sure we ask the right questions on the way.