Laravel Openid Connect Laravel Package

Product Decisions This Supports

• Enterprise SSO / "Sign in with Okta, Azure AD, Entra ID, Keycloak, Auth0, Google Workspace": the package handles the OpenID Connect authorization-code flow inside Laravel's existing auth system, so SSO becomes a scoped integration ticket rather than a multi-sprint identity project. Directly unblocks B2B deals gated on "do you support SAML/SSO?" — note this is OIDC, so SAML-only buyers still need a separate answer.
• Build vs. buy on identity: the strongest argument is that it lets you buy the identity provider (Okta/Entra/Keycloak) and not buy the middleware (Auth0/Clerk/WorkOS/FusionAuth). You keep the IdP contract and drop the per-MAU middleware fee. Material at scale — worth modeling against per-MAU middleware pricing before committing.
• Killing password auth on an existing Laravel app: incremental, reversible migration. Ship OIDC as an alternative login route behind a flag, migrate internal/admin users first (highest-risk accounts, lowest support cost), then customer orgs. No user-table rewrite and no forced password reset event.
• Multi-tenant / per-organization identity routing: relevant if you're selling to companies that each bring their own IdP. Supports the "each tenant configures their own provider" roadmap item without committing to a middleware vendor's org model.
• Roadmap sequencing input: the 3.3.0 release is maintenance-only (PHP 8.5 CI, one deprecation fix). That is a deliberate signal to plan on this package for the protocol plumbing, and to budget separately for the gaps — session/device management, MFA policy enforcement, SCIM provisioning, admin self-service UI. Don't let a roadmap slide assume the package covers those.
• Infra upgrade calendar: PHP 8.5 readiness with CI coverage means adopting PHP 8.5 isn't blocked by your auth layer. Feeds directly into the framework-upgrade decision rather than being discovered as a blocker mid-upgrade.

When to Consider This Package

Adopt when all of these hold:

• Laravel/PHP is the stack and you're on a currently supported Laravel version — this is a thin, convention-following integration, not a portable identity library. Outside Laravel, evaluate a standalone OIDC client instead.
• Your counterparties speak OIDC, not SAML. Enterprise buyers who mandate SAML 2.0 are not served by this; you'll need a broker (Auth0/WorkOS/Keycloak as a SAML-to-OIDC bridge) regardless.
• You're comfortable owning identity policy yourself: role mapping, tenant-to-provider mapping, account linking, and what happens when an IdP admin deprovisions a user. The package validates tokens; it does not decide who gets in.
• You need auth session behavior, not authorization. Roles, permissions, and org membership stay in your app.

Look elsewhere when:

• MFA, step-up auth, or device/session management are product requirements. The IdP enforces policy at its own login screen; you get whatever it gives you. If you're the IdP-adjacent product, this is the wrong layer.
• You need automated user provisioning (SCIM, HRIS sync, JIT lifecycle). Not in scope — plan a separate integration.
• You want a vendor to own identity uptime and support SLAs. A community package with a small maintainer base is a bus-factor consideration; verify release cadence and issue responsiveness before making it load-bearing for revenue-gating login.
• Social login is the only goal. Laravel Socialite / SocialiteProviders is the lower-friction path for "Sign in with Google/GitHub" B2C use cases; OIDC machinery is overhead there.
• You're pre-product-market-fit with a handful of users. Email/password or a hosted auth service ships faster and is cheaper to operate than owning IdP configuration.

Also worth flagging as a hold condition: this 3.3.0 release is a small maintenance bump, not a feature or security release. Adopting on the strength of it is fine, but it's not evidence of a large contributor base — confirm the project's recent release history and open-issue backlog before it becomes the only door into your product.

How to Pitch It (Stakeholders)

One-liner: a small, actively maintained Laravel package that lets us plug enterprise identity providers into our existing login flow, instead of paying a middleware vendor per user.

For executives: Enterprise prospects ask for SSO in security review, and it routinely stalls deals late in the cycle. We can satisfy the OIDC variant using our existing Laravel auth, with the customer's own identity provider doing the authentication. That converts a common procurement blocker into a configurable feature, and it displaces a per-MAU middleware line item. What it does not cover — SAML-only buyers, MFA policy, automated user provisioning — needs an explicit roadmap decision; I recommend we scope those separately rather than assume they come free.

For engineering: thin OIDC client over Laravel's auth guard — discovery, JWKS, token validation, userinfo. 3.3.0 is maintenance only: PHP 8.5 CI coverage and a fix for the deprecated ReflectionMethod::setAccessible(), which matters because it means the auth layer won't block a PHP 8.5 upgrade. No breaking changes, no migration work. Our integration surface is the provider config, claim-to-user mapping, and the tenant/provider resolution logic — that last piece is ours to design and is where the real estimate lives. Please also confirm the package's dependency and maintenance posture before we make it the only path to login.

Ask: approve a timeboxed spike to ship OIDC behind a feature flag for internal users, and a separate product decision on whether SAML and provisioning are in scope for the enterprise tier.