Openid Connect Laravel Package

Product Decisions This Supports

• Enterprise SSO / "Sign in with us" roadmap items. This package turns a Laravel app into a standards-compliant OpenID Connect identity provider (discovery document, JWKS, authorization/token/userinfo endpoints, layered on Passport). That directly enables the B2B ask we keep getting from enterprise buyers: "can our IdP/Okta/Azure AD/Keycloak connect to you?"
• Build vs. buy for identity. The realistic alternatives are Auth0/Okta/WorkOS/Descope (recurring per-MAU cost, vendor lock-in, but fast and battle-tested) or hand-rolling OIDC (weeks of security-sensitive work). This package is the "build cheaply, own the identity surface" option and should be priced into that comparison.
• Partner/third-party integration strategy. If we want other products or partners to authenticate our users, this is the enabling primitive. That shapes whether integration deals are "we'll ship OAuth later" or "yes, in this quarter."
• Compliance and procurement conversations. OIDC discovery + JWKS is table stakes in security questionnaires (SOC 2, ISO 27001, public-sector RFPs). Adopting this moves those answers from "roadmap" to "supported."
• Interop risk tracking. The 1.2.1 fix corrects the scopes_supported key in /.well-known/openid-configuration — a metadata field strict relying-party libraries read during discovery. Small in code, meaningful in product terms: it removes a class of "your IdP doesn't work with our client" support tickets.
• Release cadence signal for planning. A patch-level, single-fix release suggests a stable, low-churn dependency — good for a platform component we don't want to babysit.

When to Consider This Package

Adopt when:

• The Laravel app already uses (or will use) Laravel Passport — this package extends it rather than replacing it, so it's low-marginal-cost if Passport is in place.
• We need to be the identity provider (issue tokens for our users to other apps), not the relying party (consume Google/Okta logins). For the latter, use Socialite or an OIDC client library instead.
• We want standard OIDC endpoints with minimal custom code and are comfortable owning the security posture ourselves — key rotation, token lifetimes, consent UX, and audit logging are our responsibility, not the package's.
• Traffic and tenant count are moderate; a self-hosted IdP is a reasonable cost story below the MAU thresholds where managed identity gets expensive.
• The team has PHP/Laravel depth and can review security-critical paths and keep dependencies patched.

Look elsewhere when:

• We need SAML, SCIM provisioning, adaptive MFA, anomaly detection, or admin-facing IdP configuration UI — a managed provider is materially cheaper than building these.
• Uptime of authentication is business-critical and we don't want to staff it (auth downtime = full product downtime).
• We're not on Passport, or we're on a non-Laravel stack, or we're already committed to a managed IdP contract.
• We need a certified OIDC implementation with formal conformance testing for a regulated buyer — verify this package's certification status before promising it.
• We need multi-region, high-availability identity with SLAs — that's an infrastructure commitment, not a package decision.

How to Pitch It (Stakeholders)

For executives: We can make our product a standards-based identity provider using an existing open-source Laravel package instead of buying a per-user identity vendor. That unblocks enterprise SSO conversations and partner integrations without adding a recurring SaaS line item or a multi-week security build. The trade-off is that we own the operational and security burden of authentication — so this is the right call only if we're prepared to treat identity as a supported platform component, not a side project. The latest 1.2.1 release is a small but telling fix: it corrects a discovery-metadata field that strict client libraries read, which reduces "it doesn't integrate with our system" friction in exactly the enterprise deals we're targeting.

For engineering: Version 1.2.1 is a safe patch — one fix to the scopes_supported key in /.well-known/openid-configuration, no API changes and no deprecations, so it's a drop-in upgrade. The underlying capability (OIDC discovery, JWKS, authorization/token/userinfo endpoints on top of Passport) is the piece we'd otherwise hand-roll. Before committing, we need a short spike covering: key management and rotation, token/session lifetimes, consent and scope design, audit logging, and interop testing against at least two real relying parties (e.g. a Keycloak instance and one commercial client). Estimate that spike as the gate, not the integration.