- Is nl.idaas/laravel-openid-connect an OpenID Connect client or an OIDC server?
- It is an OpenID Connect provider/server package for Laravel applications, not an OIDC client. It is intended for products that need to act as an identity provider and expose OIDC endpoints such as discovery, authorization, token, userinfo, and JWKS. If your goal is to let users log in with Google, Okta, or Azure AD, you need an OIDC client library instead.
- Can I use this package for login with Google, Okta, or Azure AD?
- No. This package is positioned as an OIDC provider, so it lets your Laravel application issue tokens and identity claims to client applications. Logging users in with Google, Okta, or Azure AD is an OIDC client consumption use case and should be handled with a client library or Laravel Socialite-style integration.
- Which Laravel, PHP, and Passport versions does this package support?
- The available overview does not provide a clear Laravel, PHP, and Passport version matrix, so compatibility must be validated against your exact stack. Treat the drop-in Passport replacement claim cautiously and test installation, migrations, signing keys, OAuth clients, scopes, and consent flows in a non-production environment. Confirm the supported matrix with the maintainers before committing to production use.
- Does this package replace Laravel Passport?
- It is positioned as a Passport-based OIDC server and drop-in replacement, but the migration should be treated as a fork-and-replace change rather than a trivial dependency swap. Inventory existing Passport guards, clients, scopes, grants, token lifetimes, signing keys, custom claims, consent screens, and database tables first. Then branch the application, swap the package in a test environment, and run your existing auth and API test suites before cutover.
- What license does nl.idaas/laravel-openid-connect use, and is AGPL-3.0 a problem for SaaS?
- The package is reported as AGPL-3.0 licensed, which can be a significant adoption risk for proprietary and SaaS products because network use may trigger source-disclosure obligations. Legal and license review should happen before engineering investment or production deployment. If your distribution or SaaS model cannot accept AGPL terms, consider a different package or a commercial identity provider.
- Does it support PKCE, refresh tokens, userinfo, discovery, and JWKS?
- The package targets OIDC provider endpoints including discovery, authorization, token, userinfo, and JWKS, and it is based on Laravel Passport-style OAuth2. However, conformance for PKCE, ID token claims, key rotation, logout, consent, and refresh behavior should be verified through a technical spike and OIDC-specific tests. Do not assume certification or full conformance without evidence from the maintainers.
- Is this package production-ready and actively maintained?
- The available assessment flags high risk for production identity workloads due to low ecosystem evidence, including around 65 stars, zero dependents, and limited maintainer depth. Teams should assume vendor-style ownership by monitoring upstream Passport changes and OIDC security updates, patching issues, and potentially maintaining a fork. Run a pilot with an internal client and define rollback criteria before exposing it to production clients.
- How do I install and configure this OIDC server in a Laravel application?
- Install it with Composer, then publish and review the package configuration and migrations before running them. You will need to configure signing keys, OAuth clients, scopes, consent behavior, redirect URIs, issuer URL, and any Passport customizations already present in the application. Because exact setup steps depend on the package version, follow the repository README and validate every endpoint in a non-production environment first.
- How do I migrate existing Passport clients, tokens, and signing keys to this package?
- Treat the migration as a fork-and-replace project: inventory all Passport usage, branch the application, and verify database schema and signing key compatibility before swapping packages. Confirm that existing resource servers and clients still accept tokens and that custom claims, scopes, grants, and consent screens behave as expected. Pilot with one internal client, stage a parallel identity provider if possible, and only then cut over production clients with rollback criteria.
- What alternatives should I consider for OpenID Connect in Laravel?
- If you need to become an OIDC provider, compare this package with Laravel Passport plus OIDC extensions, a dedicated identity provider, or a commercially supported OIDC server. If you need to consume OIDC, choose a client library rather than this provider package. Evaluate conformance testing, security disclosure policy, license terms, and maintainer support before selecting an option.