Oauthserverbundle Laravel Package

Getting Started

Treat this package as vendored, unmaintained code, not a library you depend on. The description ("oauthserver modification"), zero stars, and zero dependents tell you everything: it is almost certainly an internal fork of friendsofsymfony/oauth-server-bundle (itself a fork of bazinga/oauth-server-bundle) with local patches. There is no README worth trusting and no release cadence.

Framework reality check first. Despite the Symfony-style ...Bundle suffix, this is a Symfony bundle — it will not run inside Laravel. If you are a Laravel developer, stop here and use laravel/passport or league/oauth2-server; there is no service provider, no config publishing, no facade, and the autoloading/container model is incompatible. Only continue if the host application is Symfony (likely Symfony 2.x/3.x era).

Minimal steps if you genuinely must adopt it:

1. Add the repo as a VCS or path repository in composer.json and pin an exact commit. Do not use a floating branch.
2. Read composer.json require constraints before anything else — PHP version and Symfony version will decide whether this is even bootable on your stack.
3. Register the bundle in app/AppKernel.php (or config/bundles.php on Flex) using the namespace from the bundle's root class.
4. Diff the bundle against the matching upstream friendsofsymfony/oauth-server-bundle tag. The "modification" is the whole value proposition, so the diff is the documentation.
5. Run the bundle's Doctrine migrations / create the client, access_token, refresh_token, auth_code tables, then insert one Client row manually.

Where to look first: DependencyInjection/Configuration.php (the real config tree — upstream docs will lie to you if the alias was renamed), Resources/config/ (service wiring and security config), and the Entity/ and Storage/ directories (that is where forks usually diverge).

First use case: provision a client, hit /oauth/v2/token with the client-credentials or password grant via curl, then protect one route with the bundle's token firewall listener and confirm a Bearer request returns 200.

Implementation Patterns

Entity extension. The bundle ships mapped or abstract entities for Client, AccessToken, RefreshToken, and AuthCode. In a real app you subclass them in your own bundle, map them with your ORM config, and rebind the bundle's model parameters/service IDs to your classes. Verify whether this fork uses annotations, XML, or YAML mapping before copying any tutorial.

Security firewall wiring. Typical shape: an oauth_token (or similarly named) firewall listener for API routes, plus an anonymous firewall for /oauth/v2/token, with security.access_control allowing anonymous access to the token endpoint only. Grep Resources/config/security.xml for the actual listener ID and firewall name — forks rename these.

Grant configuration. Enabled grants are configured under the bundle alias (upstream: grant_types.driver: [client_credentials, password, ...]). Enable only what you need; each grant adds attack surface. Check whether the fork adds a custom grant (often the reason a fork exists, e.g. LDAP-backed or MFA-aware password grants).

Token storage strategy. Upstream supports Doctrine-backed storage and a fos_oauth_server.storage.driver style switch. If the fork adds Redis/memcached or a custom StorageInterface, use the bundle's own implementation rather than writing your own — token lookups happen on every request and are latency-sensitive.

Client provisioning workflow. Prefer a Symfony console command or a data fixture that creates Client records idempotently, driven from environment config (client_id, client_secret, redirect URIs). Never hand-INSERT clients in production, and never commit secrets — generate them at deploy time.

Testing pattern. Boot a test kernel with SQLite in-memory, seed a client fixture, POST to /oauth/v2/token, assert access_token presence, then assert a protected endpoint with Authorization: Bearer <token>. Add negative tests for expired tokens, bad client_secret, and revoked refresh tokens — old forks fail these.

Cross-service consumption. If a Laravel or Node app consumes this server, it only needs the token endpoint and the resource endpoints. Point league/oauth2-client (or Passport's Passport::client()) at the server; the bundle does not need to be installed on the consumer.

Gotchas and Tips

• Namespace drift is the #1 trap. Forks routinely rename FOS\OAuthServerBundle to a vendor namespace. Every service ID, container parameter, and config key in upstream documentation may be wrong. Grep the bundle for the actual alias before copying a single line of config.
• Symfony/PHP version coupling. A fork frozen at Symfony 2.8 or 3.4 will not autowire under Symfony 4+, will break on PHP 8 typed properties, and may pull abandoned transitive dependencies. Check composer.json and run composer why-not before committing.
• Refresh token rotation. Confirm whether the fork invalidates refresh tokens on use. Many old forks do not, which allows indefinite refresh-token replay. If rotation is missing, add it in your entity layer or accept the risk explicitly.
• Expiry and clock skew. Look at AccessToken::hasExpired() and the configured access_token_lifetime. Short-lived access tokens plus non-rotating refresh tokens is the usual safe configuration; document the TTLs for API consumers.
• Error semantics matter to clients. 400 invalid_grant (bad credentials/expired code) versus 401 invalid_token (bad/expired access token) versus 400 invalid_client — clients branch on these. Test each path.
• Debugging. Enable the bundle's logger channel if present, tail the access_token table directly, and check var/logs for security listener denials. Most "it works locally" failures are firewall access_control ordering, not token logic.
• Extension points. Swap model classes via the bundle's container parameters or a compiler pass; add custom grants by implementing the bundle's grant-extension interface and tagging the service. These two hooks cover 90% of real customization.
• Security hardening. The token endpoint is an unauthenticated credential endpoint: force HTTPS, add rate limiting at the edge, and ensure client_secret comparison is constant-time. If you are pinned to an old Symfony, check the relevant security advisories.
• Exit plan. Given zero stars and zero dependents, do not build new features directly into this bundle. Isolate it behind a thin adapter (your own TokenIssuer interface) so you can later swap to league/oauth2-server, oauth2-server-bundle, or Laravel Passport without touching domain code.