Laravel Openid Connect Laravel Package

Product Decisions This Supports

• Build vs. buy on identity: This package makes the decision "do we stand up a dedicated IdP (Okta, Auth0, Keycloak, WorkOS) or extend the auth stack we already run?" concrete. If your product is already Laravel + Passport, adopting this is a days-scale experiment rather than a procurement cycle — useful for validating demand for SSO before committing budget.
• Turning your app into an identity provider, not just a consumer: The critical PM distinction. This does not let your users "Sign in with Google" — it lets other applications sign in to your Laravel app via OpenID Connect. That unlocks a specific roadmap bet: becoming the SSO hub for a suite of first-party apps, or offering "Log in with [Our Product]" to third-party developers and partners.
• Enterprise / platform readiness: ID tokens, a discovery document, and a userinfo endpoint are the difference between "we speak OAuth 2.0" and "we are usable as an identity layer." If your roadmap includes a developer platform, marketplace, or partner integrations, OIDC compliance is table stakes rather than a nice-to-have.
• Consolidating a fragmented internal estate: For organizations running several Laravel services, this is a low-cost path to single sign-on across them without introducing and operating a separate IdP — a real OpEx avoidance decision.
• Migration sequencing: As a drop-in Passport replacement, it de-risks the roadmap item "add OIDC" into a contained spike instead of a multi-quarter identity rewrite. Deciding whether to schedule that spike is the actual decision on the table.
• Security posture trade-off: Authentication code is an adversarial surface. A 65-star package with zero dependents means limited external review; the PM decision is explicitly accepting that risk in exchange for speed.

When to Consider This Package

Consider it when:

• You are already running Laravel Passport and the ask is narrowly "add OIDC on top," not "replace our identity architecture."
• Your consumers are first-party or trusted-partner applications — internal tools, sibling Laravel services, a mobile client needing ID tokens.
• You have PHP/Laravel engineering capacity and can read, patch, and fork the auth code yourself; the maintainer is a single commercial entity (Limosa) with no SLA and no visible dependent base.
• Your legal team clears AGPL-3.0, or you can obtain a commercial license. This is a hard gate for closed-source SaaS, since network-serving a modified version triggers source-disclosure obligations.
• You want a time-boxed spike to prototype an SSO story and measure partner/enterprise demand before funding a real IdP.

Look elsewhere when:

• You need to consume OIDC from an external IdP — use Laravel Socialite or a client library; this is the wrong side of the protocol.
• You require SAML, SCIM provisioning, MFA policy engines, adaptive/step-up auth, or audit-grade logging — that is Keycloak, Zitadel, Ory, Auth0, or WorkOS territory.
• You need OIDC certification, FAPI conformance, or a vendor security questionnaire you can actually answer — a 65-star package will not survive procurement review.
• AGPL is a non-starter and no commercial license is available at an acceptable price.
• Your auth stack is not Laravel/Passport — the drop-in value evaporates entirely.
• Identity is core to your product's differentiation; a single-maintainer dependency on the most security-sensitive path in your system is a poor long-term foundation.

How to Pitch It (Stakeholders)

To executives: We can add standards-based single sign-on to our Laravel platform in days instead of buying an identity vendor or running a multi-quarter build. It converts our existing Passport investment into an OpenID Connect provider, which is the prerequisite for a partner/developer ecosystem and for consolidating login across our internal apps. The caveats are real and worth stating plainly: the license is AGPL, which needs legal sign-off before any production use, and the project is small — one maintainer, no meaningful adoption base. Recommendation: fund a two-week spike to prove the integration and quantify demand, and treat it as a tactical accelerator, not a strategic identity platform. If SSO becomes a committed roadmap item with enterprise customers attached, we should plan to graduate to a supported IdP or take ownership of the code.

To engineering: It is a drop-in replacement for Passport, so the integration surface is small and reversible — you keep your existing user model, grants, and token flow and gain discovery, ID tokens, and userinfo. Expect to pin a version, vendor or fork it, and own security patching, because upstream velocity and community review are thin. Flag any place we would need to modify the package, since AGPL's network clause makes modifications a disclosure event.

To legal/security: AGPL-3.0 with a network-use trigger. Any modification we serve to users obligates us to offer that source. Confirm whether a commercial license is available from the maintainer before we design around it, and treat the dependency as supply-chain risk requiring a fork-and-own contingency.