Oauth2 Server Token Endpoint Laravel Package

Product Decisions This Supports

• Whether to build an OAuth2 authorization server at all. This package is the "mint the token" half of an OAuth2 server: it handles the POST /token request for the standard grants (authorization code, client credentials, password, refresh token). A PM evaluating an API platform, partner marketplace, or mobile app backend needs to decide whether token issuance is a product-building exercise or commodity plumbing — this package makes the case that it is the latter.
• Public API / partner integration roadmap. If the roadmap includes third-party developers, scoped access, and delegated authorization, this is the component that turns "we have an API" into "we have a platform." It supports decisions about scope design, token lifetimes, refresh-token rotation, and revocation SLAs.
• Machine-to-machine (M2M) authentication for internal services. The client-credentials grant path is directly relevant to service-to-service auth; it lets you standardize backend auth on OAuth2 rather than bespoke API keys.
• Build vs. buy vs. assemble. The package represents the "assemble from spec-level components" option: you take the token endpoint and supply the grant logic, token storage, client registry, and PSR-7/HTTP glue yourself. The PM decision is assemble-from-components vs. one-stop-shop (Laravel Passport) vs. hosted IdP (Auth0/Keycloak/Cognito).
• Compliance-driven work. Token endpoint semantics (error formats, grant_type handling, invalid_client responses) are where auditors and integration partners look first. A spec-focused component reduces the risk of "works with our client, fails with theirs."
• Migration/consolidation triage. With zero dependents and no visible star activity, this is a candidate to flag in a dependency-audit decision: keep, wrap, or replace ahead of a security review rather than after.

When to Consider This Package

Consider it when:

• You are already committed to the Spomky-Labs / php-oauth2-server ecosystem and need the token endpoint as one piece of a modular server. It is explicitly a component — adopting it means adopting the surrounding grant-type and storage packages too.
• You need strict RFC 6749 token-endpoint behavior, custom grant types, or fine-grained control over token issuance and you have engineering capacity to wire the surrounding pieces.
• Your stack is PHP/Laravel but you need framework-agnostic OAuth2 primitives (the package is PSR-oriented, not Laravel-coupled), for example when the auth service is separate from the Laravel application.
• You are issuing tokens for a small number of trusted first-party or partner clients where a hosted IdP is overkill on cost or data-residency grounds.

Look elsewhere when:

• You are greenfield on Laravel. Laravel Passport gives you a complete, first-party, actively maintained OAuth2 server out of the box; Laravel Sanctum covers first-party SPA/mobile tokens with far less ceremony.
• You want a maintained, framework-agnostic server: league/oauth2-server is the conventional choice.
• You do not want to own the security surface. Token issuance is authentication-critical code; a hosted IdP removes key rotation, brute-force protection, and audit logging from your backlog.
• You need OIDC / SSO / social login rather than plain OAuth2 — this package does not give you identity, only authorization tokens.
• Maintenance signal is the deciding factor here. This is a single sub-package of a larger project with no visible dependents. Before committing, engineering must confirm: last release date, compatibility with your PHP/Laravel version, whether the parent project is still maintained, and whether a supported upgrade path exists. Treat "unmaintained auth component" as a blocking risk, not a footnote.

How to Pitch It (Stakeholders)

For executives: OAuth2 token issuance is standard, well-understood plumbing — every serious API platform has it, and none of them differentiate on it. The strategic question is not "should we use this library" but "do we want to own an authorization server." Owning it costs engineering time and creates a permanent security-maintenance obligation; outsourcing it to a hosted identity provider costs money and some vendor lock-in. My recommendation is to make that call explicitly at the platform level rather than let it be settled by whichever library an engineer reaches for first.

For engineering: This is the token endpoint component of the Spomky-Labs OAuth2 server — the POST /token handler for the standard grants. It is a piece, not a product: you must supply grant implementations, client storage, token persistence, and HTTP integration, and you inherit the parent project's release cadence. Adoption is only defensible if we are already standardized on that ecosystem or have a specific need for its extensibility. Otherwise, Passport (Laravel) or league/oauth2-server (framework-agnostic) is the lower-risk default, and a hosted IdP is the lower-effort one.

The ask: a short spike — two days — to confirm maintenance status, PHP/Laravel compatibility, and the realistic integration surface. Until that spike lands, this package should not appear in an architecture diagram or a delivery estimate. The output should be a one-page recommendation: adopt as part of the Spomky stack, replace with Passport/league, or delegate to a hosted IdP.