Oauth2 Server Password Client Laravel Package

Product Decisions This Supports

• Auth architecture for first-party clients. It implements the Resource Owner Password Credentials (ROPC) grant, letting a trusted first-party client (mobile app, CLI, desktop agent, internal service) exchange a username/password directly for an access token instead of bouncing through a browser redirect. That's a genuine product decision: do our users ever need to leave the app to log in?
• Build vs. buy on token plumbing. It's an argument for "buy" — a few hundred lines of grant logic you don't write. At 0 stars / 0 dependents, though, the real comparison is this package vs. ~1 day of in-house work vs. league/oauth2-server, not vs. a supported vendor product.
• Legacy modernization sequencing. Its best use is phased migration: stand up OAuth2 tokens in front of an existing PHP user table now, swap in a proper IdP later. It supports the roadmap call "secure the API first, re-architect identity second."
• Ecosystem lock-in check. It only pays off if you're already on Spomky-Labs' oauth2-server. Adopting it otherwise quietly commits you to an end-of-life framework for one grant type.
• Not a differentiator. No user will ever see this. Its value is speed to a working token endpoint, not capability — useful to say out loud so nobody mistakes it for an identity strategy.

When to Consider This Package

Consider it when:

• You are already running Spomky-Labs' oauth2-server (1.x era) and need password-grant support as a plug-in client type.
• The endpoint is low-stakes: an internal tool, an admin console, a controlled first-party client.
• Your team is willing to read, test, and patch the library itself — assume you will, repeatedly.
• The user store and client registry are small and fully under your control.

Look elsewhere when:

• Greenfield. Use league/oauth2-server (the maintained successor lineage) or a hosted IdP — Keycloak, Ory, Auth0, Cognito.
• You need MFA, SSO, social login, or passwordless. ROPC structurally cannot support them; the client sees the password.
• You're targeting OAuth 2.1. The password grant is deprecated there; authorization code + PKCE or device flow is the sanctioned path. Building on ROPC is building toward a migration.
• Third-party or untrusted clients are involved. Never ship ROPC to those, full stop.
• You need a security process. Zero stars, zero dependents means no downstream canaries, no community CVE-watching, no maintainer answering issues. You are the maintainer.
• Your PHP/PSR stack is current. These older Spomky-Labs packages frequently lag on PHP 8.x and newer PSR-7/PSR-17 implementations — verify compatibility before committing, not after.

How to Pitch It (Stakeholders)

To executives: This is a small, single-purpose library that lets our PHP backend issue OAuth2 tokens from a username and password. It's a tactical shortcut, not a platform bet. Honest framing: it saves roughly a day of engineering and carries real maintenance and security-patch risk, because it has effectively no users and no active maintainer. I'd green-light it only as an interim step — with a named owner, a pinned version, and a dated plan to move to a maintained identity provider. Do not hang a customer-facing login or account roadmap on it.

To engineering: Treat it as a reference implementation we own, not a dependency we consume. Budget for: pinning the exact version (or vendoring/forking it), tests around client validation, credential checks, error responses, and token expiry, plus a compatibility pass against our PHP and PSR versions. If we aren't already on Spomky-Labs' server, the honest alternatives are league/oauth2-server or a day implementing the grant ourselves — both give us a maintainer and a security process. Also flag now: the password grant is deprecated in OAuth 2.1. If mobile clients are on the roadmap, PKCE is the better shape, and we should say that before the architecture hardens.