Weave Code
Oauth2 Server Utils Laravel Package
spomky-labs/oauth2-server-utils
Utility helpers for the spomky-labs/oauth2-server PHP library, designed to simplify common OAuth2 server setup and token-related tasks. Useful for developers building standards-compliant authorization servers with the Spomky Labs OAuth2 framework.
OAuth2 Server Request Utils
Frequently asked questions about Oauth2 Server Utils
- What is spomky-labs/oauth2-server-utils used for?
- It is a thin, PSR-7-oriented parsing layer that converts incoming HTTP requests into typed OAuth2 request objects such as authorization requests, token requests, and grant-specific request classes. Those objects are then handed to an authorization server implementation. The package deliberately contains no grant logic, token issuance, key management, or storage, so it is only the request-normalization boundary of a larger OAuth2 server. In practice you would place it in middleware or a controller-layer adapter in front of an authorization or token endpoint.
- Does spomky-labs/oauth2-server-utils work with Laravel out of the box?
- No. Laravel's HTTP layer is not PSR-7, so integration requires symfony/psr-http-message-bridge plus a PSR-7 implementation such as nyholm/psr7 or laminas-diactoros. The package ships no service provider, config file, or facade, so all wiring is manual. That extra bridge also adds a version matrix you have to maintain alongside your Laravel upgrade path.
- Should I use oauth2-server-utils instead of Laravel Passport?
- Generally no, because the fit is duplicative rather than complementary. Laravel Passport already fills the request-parsing slot via league/oauth2-server, whose request classes are the direct, maintained descendants of this code. Adopting this package means either duplicating Passport or assembling an authorization server from parts. The only defensible case is a fully bespoke server that brings its own grant, token, and persistence implementations, at which point you own most of the system anyway.
- Which PHP and Laravel versions does oauth2-server-utils support?
- Expect a PHP 7.x era constraint set from composer.json, which means installing unmodified on PHP 8.2 or 8.3 is unlikely without a fork or a constraint override. Always verify the actual composer.json and last release date on Packagist before planning anything. If your target runtime is PHP 8.2 or 8.3 and the constraints block installation, that ends the evaluation unless you fork the code.
- Does oauth2-server-utils support PKCE, OpenID Connect, or modern grant types?
- Assume it does not. Spec errata and modern features such as PKCE per RFC 7636, OIDC, DPoP, and mTLS landed upstream in league/oauth2-server v5 and later, not in this package. If your requirement includes any of those, this package is disqualified outright. Only a fork with its own maintained test suite would make it viable.
- How do I install and wire up spomky-labs/oauth2-server-utils?
- It is Composer-installable with PSR-4 autoloading, so a standard composer require pulls it in. The real work is the wiring: add symfony/psr-http-message-bridge and a PSR-7 implementation, then adapt Laravel's request into a PSR-7 request before invoking the parser. There is no auto-discovery, so you register the adapter in a middleware or controller yourself. Timebox a spike that installs it in your target runtime and parses one authorization request end to end before committing further.
- Is spomky-labs/oauth2-server-utils maintained and safe for production?
- Treat it as high risk. It has zero dependents and no star signal, so there is no observable production usage and you would be the only party exercising this code path. This is also security-sensitive code: it decides what a client is asking for, so mis-parsing grant_type, scope, redirect_uri, or client authentication is an auth-bypass class of defect. Abandoned code sitting in that position is a standing liability, and the abstraction was superseded upstream in league/oauth2-server.
- Can I unit test the parsed request objects from oauth2-server-utils in isolation?
- Yes, and that is the cheapest part of any spike. The parsed objects are plain typed classes, so you can assert on grant_type, scope, redirect_uri, and client authentication details without standing up a full authorization server. Feed in crafted PSR-7 requests covering malformed and edge-case inputs, since those are exactly the paths where an auth bypass would hide. Keep that suite regardless of whether you keep the package or migrate to League request types.
- What if oauth2-server-utils is already a transitive dependency in my project?
- First determine what pulled it in and whether that dependency can be removed entirely, since a transitive security-sensitive parser is worth eliminating. Run composer why or composer depends against the package name to trace the chain. If it must stay, replace the request-parsing layer with League\OAuth2\Server\RequestTypes\* and the corresponding grant classes. The shapes are close enough that a mechanical mapping is usually feasible, but budget a real sprint and a security review because the mapping touches every grant path.
- What are the alternatives to oauth2-server-utils and how do I migrate off it?
- For a standard Laravel application the answer is Laravel Passport, which routes through league/oauth2-server and treats these abstractions as already included in modern form. In a bespoke PSR-7 or Symfony stack, league/oauth2-server is the maintained home for the same interfaces. If you genuinely need a bespoke server, fork the package into a private vendored namespace and own it as source with a named maintainer and its own test suite. Migrate by swapping in League request types and grant classes, then re-run your parsing tests and a security review.
Weaver
How can I help you explore Laravel packages today?