- What does ronvanderheijden/openid-connect actually do?
- It adds the OpenID Connect identity layer on top of the PHP League's OAuth2 Server so your Laravel application can act as an OpenID Connect provider. That covers the discovery document at /.well-known/openid-configuration, JWKS exposure, authorization code flow, token handling and user info claims. It is a thin HTTP and crypto adapter over your existing user model and auth guard, not a standalone identity server.
- How do I install and set up OpenID Connect in a Laravel app with this package?
- Install it with Composer, then publish the package config and routes so the well-known, JWKS and token endpoints become available. After that you generate signing key material, register the routes, and map the claims you want to emit onto your User model. The integration surface is deliberately small, so most of the work is claim mapping and key custody rather than wiring. Do the first end-to-end test against a relying party in staging before touching production.
- Does this package work with Laravel Passport?
- Yes, Laravel Passport support is one of the package's headline features, letting you reuse the OAuth2 infrastructure Passport already provides. If you already run Passport, that usually means less custom token plumbing to maintain. Confirm your Passport major version against the package's composer constraints before committing, since the underlying League OAuth2 Server version drives compatibility.
- Which Laravel and PHP versions does this package support?
- It is aimed at Laravel 9/10-era applications running PHP 8.1 or newer, and it depends on the League OAuth2 Server and a JWT library such as lcobucci/jwt. Always read the composer.json constraints for the exact release you intend to install rather than assuming broad support. Because it sits in the authentication path, verify the Laravel, PHP and JWT dependency versions explicitly during your upgrade planning.
- Can I use this package to log users in with Google or another third-party identity provider?
- No. This package makes your Laravel application the identity provider; it does not consume an external one. If your requirement is social or third-party OIDC login, Laravel Socialite and similar client packages are the right tool and this evaluation should stop here. The distinction matters architecturally: building an IdP means owning discovery metadata, keys and claims for downstream relying parties.
- How do I generate signing keys and expose the JWKS endpoint?
- The package supports publishing public key material through a JWKS endpoint so relying parties can validate your ID tokens, and it handles kid values in the token headers. Generating the key pair is your responsibility as part of setup, so treat key material as a secret and keep it out of version control. Rotation cadence, key custody and JWKS cache TTLs are operational decisions the package enables but does not make for you, so assign an owner before go-live.
- Where is the OpenID Connect discovery document served and what should it contain?
- It is served at /.well-known/openid-configuration and acts as a contract with every relying party in your estate. Fields such as scopes_supported, response_types_supported and id_token_signing_alg_values_supported are read by clients at bootstrap time to decide how to talk to you. Drift in these values causes silent consumer failures rather than loud ones, so validate the document against the OIDC discovery spec in CI. Version 1.2.1 of this package fixed a scopes_supported issue, which shows how narrow the integration seam can be.
- How do I test an OpenID Connect provider before going live?
- Unit tests are not enough here; add a conformance check that diffs your discovery document against the OIDC spec and against the previous release. Then exercise the full authorization code flow from a real relying party in staging, including token validation and user info response shape. The most valuable test is the one that catches metadata drift before your consumers do, since they will fail quietly when a supported scope or signing algorithm disappears.
- What are the production risks of using this package in the auth path?
- Protocol conformance and key management are the two dominant risks, because both fail silently at the consumer boundary. Version pinning matters too: pre-2.x versioning on a security-adjacent package means semver is a courtesy, so pin exact versions and read every changelog. It is also a single-maintainer package, so plan for the bus factor and keep an exit path in mind. Check that no reverse proxy, API gateway or CDN is already serving or rewriting /.well-known/* before you deploy.
- How do I migrate existing relying parties to this package from a bespoke token endpoint?
- Run the package's discovery and JWKS endpoints alongside your legacy issuer first, then point one low-risk relying party at the new issuer and prove token validation parity. Never change the iss value in place, because doing so invalidates every cached token and every relying party's stored configuration. Decommission the old path only once every consumer has been migrated and validated against the new metadata.