Laravel Oidc Laravel Package

Product Decisions This Supports

• Enterprise SSO on the roadmap, not a custom build. This package is a standards-based OpenID Connect (OIDC) relying party for Laravel — discovery, ID token validation, and login flow handling. It answers the recurring "can we log in with Okta / Microsoft Entra ID / Google Workspace / Keycloak / Auth0?" ask without a bespoke security-critical implementation.
• Account linking and multi-IdP support (new in v1.3.0). The optional OidcIdentity model, HasOidcIdentities trait, and publishable create_oidc_identities_table migration let a single user record map to one or more OIDC identities, uniquely keyed on issuer + subject. Product-wise this unlocks:
  • linking an existing password account to a corporate identity instead of creating duplicates;
  • supporting two IdPs for one tenant (e.g. post-acquisition, contractor vs. employee directory);
  • "log in with work or personal account" flows, and clean de-provisioning when an identity is unlinked.
• Opt-in data model = low-risk sequencing. Because the migration is opt-in (vendor:publish --tag="oidc-migrations") and the table name is configurable (oidc.identities_table), we can ship authentication first and defer identity persistence to a later milestone behind a feature flag. No forced schema migration on existing tenants.
• Platform upgrade unblocked. Allowing guzzlehttp/guzzle ^7.8 restores installability on Laravel 11 and 12. That directly serves a framework-upgrade OKR rather than leaving SSO pinned to an EOL Laravel version — a common cause of "we'll do SSO after the upgrade" slipping indefinitely.
• Build vs. buy tilt toward adopt. OIDC discovery, JWKS rotation, nonce/state handling, and clock-skew-tolerant token validation are commodity but easy to get subtly wrong. Adopting a small package and owning the integration layer is usually cheaper than owning the protocol layer.
• Explicitly out of scope, so plan around it: SAML, SCIM provisioning, group/role mapping, MFA and step-up policy. If any of those are in the same customer commitment, they are separate line items, not free riders on this package.

When to Consider This Package

Good fit when:

• The app is Laravel 11 or 12 and the identity provider speaks OIDC (most modern IdPs expose a .well-known/openid-configuration endpoint).
• You want configuration-driven setup with no vendor lock-in and no per-seat auth fees.
• You have (or will build) your own user/tenant provisioning logic and need the login flow, not a full identity platform.
• You specifically need identity-to-user linkage across one or more issuers — the v1.3.0 additions are the differentiator here.
• Your team is comfortable owning an integration's test coverage and tracking upstream releases.

Look elsewhere when:

• The customer's IdP is SAML-only — this package does not cover it, and a bridge (e.g. an IdP-side OIDC app) is a separate decision.
• You need directory sync, group-to-role mapping, or automated provisioning out of the box; that is SCIM/identity-governance territory.
• You require a commercial SLA, vendor security questionnaire, SOC 2 attestation, or indemnification — an open-source, single-maintainer package will not clear procurement in regulated buying cycles.
• You are already paying for a managed auth provider whose SDK covers SSO; the managed option may be cheaper than OSS plus internal maintenance once support and upgrade labor are counted.
• You need passkeys, MFA orchestration, session policy, or step-up authentication as product features.
• You need per-tenant runtime IdP configuration at scale — validate that discovery settings can be overridden per request rather than frozen in config, before committing.
• Your security posture forbids adding a dependency in the authentication path that the team cannot audit and patch internally.

Due diligence before adopting: confirm the maintainer's release cadence and issue responsiveness, pin the version, and write integration tests around the callback path so an upstream regression fails your CI rather than production login.

How to Pitch It (Stakeholders)

To executives: We have a recurring enterprise requirement to sign in with customers' existing corporate identity providers. This package gives us that capability as an adopted open-source component rather than a custom build, so we avoid spending engineering weeks on security-sensitive protocol code with no differentiation value — and we pay no per-user auth fees. The new release also removes a dependency conflict that was blocking our Laravel 11/12 upgrade, and adds optional identity linking so one user account can connect to multiple identity providers, which is what multi-tenant and post-merger customer scenarios actually require. Risk is a single-maintainer dependency with no commercial support; we mitigate with version pinning, automated login tests, and keeping password auth as a fallback. Ask: approve a timeboxed integration spike, with the opt-in migration deferred to a follow-up milestone.

To engineering: v1.3.0 relaxes the Guzzle constraint back to ^7.8, so the package installs cleanly on Laravel 11 and 12 — this unblocks the framework upgrade. It also adds an optional OidcIdentity model and HasOidcIdentities trait with a publishable create_oidc_identities_table migration, uniquely keyed on issuer + subject, and a configurable oidc.identities_table. Nothing is mandatory: no schema change until we publish and run the migration. Recommended sequence: adopt for login only, wrap the callback in feature-flagged tests, then evaluate identity linking as a second step. Treat the protocol layer as third-party and the provisioning/role-mapping layer as ours.