Openid Connect Laravel Package

Product Decisions This Supports

• Build vs. buy on identity. Delegating authentication to an OIDC provider removes an entire roadmap line item: password storage, reset flows, MFA, account recovery, session hardening. This package is the cheapest path to that decision in a Laravel codebase.
• Enterprise / public-sector go-to-market. Federated login (Entra ID, Keycloak, AD FS, national eID schemes) is frequently a hard requirement in public-sector and enterprise procurement. Supporting it turns an RFP blocker into a config task.
• Roadmap sequencing. "Enterprise SSO" moves from a quarter-long project to a release-scoped config change. That frees capacity for differentiating work.
• Multi-provider and per-tenant IdP strategy. Discovery-document configuration means onboarding a second or third provider is configuration plus claims mapping, not new integration code. This underpins market expansion and tenant-specific identity choices.
• Authorization model decisions. Claims mapping pushes role, group, and organisation attributes from the IdP onto the local user model — enabling tenant-aware permissions and seat provisioning without building an admin console.
• Vendor/architecture posture. It is a thin, Laravel-native glue layer over an OIDC client. It does not own your authorization model, so it stays replaceable — a low-regret decision.

When to Consider This Package

Consider it when:

• You are on Laravel/PHP and need the OIDC authorization-code flow, not just OAuth2 social login.
• Your identity provider is standards-compliant and publishes a discovery document.
• You want environment-driven, multi-provider configuration instead of hand-rolled auth controllers.
• You have a small team with no dedicated identity engineer.
• A buyer or regulator requires federated login but you have no SSO roadmap yet.
• You are willing to read the source, pin a version, and effectively own it.

Look elsewhere when:

• You need SAML — this is OIDC only.
• You need broad social login — Laravel Socialite is the fit.
• You need identity lifecycle management: SCIM provisioning, admin UI, fine-grained policy. This maps claims; it does not manage users.
• You need back-channel logout, token refresh rotation, or session management — verify coverage explicitly, as thin wrappers commonly omit these.
• You require a vendor with an SLA. With one star, zero dependents, and no commercial backing, this is a supply-chain risk; adopt only with a fork plan.

How to Pitch It (Stakeholders)

To executives: "We get out of the password business. One small dependency plus a configuration file per customer identity provider lets enterprise and public-sector buyers sign in with credentials they already have. It takes password reset, credential storage, and MFA out of our scope — and reduces our compliance surface accordingly. The cost is small; the unlock is procurement-grade."

To engineering: "It is a thin Laravel auth integration for the OIDC authorization-code flow: discovery-based provider config, token exchange, userinfo retrieval, and claims mapped onto your user model. Small, readable surface area, straightforward to swap. The caveat is adoption — near-zero stars and no dependents means we treat it as a well-scoped starting point we own, not a supported product. Budget a day for review, pin the version, wrap it behind our own auth interface, and keep the fork cheap."

Shared risk note: the value here is the pattern plus a head start, not a maintenance guarantee. Mitigate with a pinned version and an internal abstraction — then the downside is bounded to a day of work.