- What does klapaudius/oauth-server-bundle actually do?
- It is a Symfony bundle that turns a PHP application into an OAuth 2.0 authorization server. It ships endpoints and services for issuing, refreshing, and validating access tokens, plus Doctrine-backed storage for clients, scopes, access tokens, and refresh tokens. It builds on Symfony Security, so protected resources are guarded with the framework's familiar firewall and access-control configuration.
- Can I use klapaudius/oauth-server-bundle in a Laravel application?
- Not natively. The package is a Symfony bundle wired through the Symfony kernel and Security component, with no Laravel service provider or facade, so there is no drop-in installation in a Laravel app. Most Laravel teams use Laravel Passport or a standalone OIDC server instead, and only reach for this bundle when the authorization server itself runs on Symfony. Bridging it would mean reimplementing the security integration yourself, which is usually more work than adopting a Laravel-native package.
- Which OAuth2 grant types does the bundle support?
- It supports the four core grants: authorization code, password, client credentials, and refresh token. Authorization code is the flow you need for OIDC-style logins with SPAs, mobile apps, and third-party relying parties. Grant and storage implementations are exposed as extensible services, so custom flows are possible without forking the bundle.
- How do I install and configure the OAuth server bundle?
- Install it with Composer, register the bundle in config/bundles.php, then publish and adjust the package configuration for your client, scope, and token settings. Token lifetimes, enabled grants, and client defaults are all set in that configuration rather than in code. After configuring, run the Doctrine schema migration so the client, access token, and refresh token tables exist.
- What changed in version 6.0.0 of the bundle?
- Version 6.0.0 makes nonce and auth_time first-class attributes of the authorization code, so the token endpoint can mint a correct id_token without the integrator maintaining out-of-band state. That removes a class of homegrown workarounds around OIDC replay protection and max_age handling. It ships as a major version rather than a patch because it expands interfaces and changes storage signatures.
- Is the 6.0.0 upgrade breaking, and what has to change?
- Yes, and it is a compile-time break rather than a deprecation. AuthCodeInterface gains setNonce() and setAuthTime(), so any local implementation fatals until both methods exist, and OAuthStorage::createAuthCode() changes signature so subclasses or wrappers overriding it violate LSP and error. The Doctrine ORM, MongoDB, and CouchDB mappings also add nullable nonce and auth_time fields, which means a schema migration on whichever backend you actually run.
- How do I keep the OIDC nonce alive through a custom consent screen?
- The nonce survives the consent round trip through a hidden form field, so any custom consent template that does not render that field silently drops it. Nothing throws an error: the token request simply produces an id_token without a nonce claim, and the conformance failure surfaces later in staging or at a customer. If your consent view is customised, add the hidden field and have its owner assert its presence in a test.
- Where does auth_time come from, and why is it sometimes null?
- The bundle only carries auth_time, it does not know when the user actually authenticated, so your login flow has to stamp it. If nothing sets it, the claim stays null, max_age requests cannot be honoured, and clients receive a freshness claim they cannot trust. Capture the authentication timestamp at the point of credential verification and confirm it survives SSO and session-restore paths where the user is not authenticating right now.
- Which persistence backends are supported, and will I need a data backfill?
- Doctrine ORM, MongoDB, and CouchDB mappings all gain nullable nonce and auth_time fields, so the change is a schema migration rather than a data backfill, since nulls are semantically correct. On large auth_codes tables the risk is low, but review index definitions on MongoDB and CouchDB where they are declared explicitly. If you run a custom storage adapter, treat the upgrade as a refactor and audit createAuthCode overrides before deploying.
- Should I upgrade to 6.0.0 now or stay on 5.x for a while?
- Take 6.0.0 when you can absorb the interface change, the storage signature change, the schema migration, and the consent template update in a single window. If no downstream relying party validates nonce or requests max_age today, holding on 5.x until your next scheduled maintenance window is reasonable, but the conformance debt does not disappear. Snapshot-style tests asserting exact id_token claim sets will need updating whenever you move.