Openid Connect Claims Laravel Package

Product Decisions This Supports

Feature scope for identity and access. This package models the OpenID Connect ID token claim set as a typed object (iss, sub, aud, exp, iat, nonce, auth_time, acr, amr, azp, at_hash, c_hash). It supports the decision to treat identity claims as a first-class domain object rather than passing raw decoded JWT arrays through the application — which in turn determines whether you can reliably audit "who logged in, when, and with what assurance level." That matters for session policy, step-up authentication, and compliance logging.

Build vs. buy vs. assemble for SSO. If your roadmap includes "Sign in with Google/Okta/Azure AD/Keycloak" or B2B multi-tenant SSO, this package is a candidate component in the "assemble" path: buy the protocol work from the OIDC provider, assemble the token validation in-house. Comparing it against a full SDK (Auth0, Okta, Laravel Socialite) or a hosted identity provider is a concrete roadmap fork, and this package sits at the low end of that spectrum — narrow, MIT, no vendor relationship.

Multi-tenant and B2B authentication design. The claim set shape drives product behavior you will eventually sell: tenant-scoped sub identifiers, aud/azp validation for multi-audience tokens, acr/amr for asserting MFA was actually performed. If the roadmap has enterprise tiering, these claims are the contract with enterprise IdPs and should be decided before the auth layer is written.

Architecture and security review inputs. Adopting or rejecting it forces an explicit decision on token validation ownership (library vs. hand-rolled vs. IdP-side), which is the kind of thing security review will ask about. A small, auditable claims object is far easier to defend in a review than ad-hoc array access scattered across controllers.

Not supported: this is not an OIDC client, not a JWT parser, and not a Laravel package — it supplies no discovery, no token exchange, no signature verification. Do not let it anchor a roadmap item on its own.

When to Consider This Package

Consider it when:

• You are already in the PHP/League OAuth2 ecosystem and want the claims value object to match the rest of that stack.
• Your need is only the typed ID-token claim set: construction, validation of required claims, and named accessors for sub, aud, exp, nonce, and the assurance claims. It is intentionally small.
• You want an MIT-licensed, dependency-light building block you can vendor or fork with minimal review surface.
• You are prototyping an SSO flow and want the claim semantics correct before committing to an implementation.

Look elsewhere when:

• Production dependency risk is unacceptable. Last release was May 2016, ~16 stars, and effectively no dependents or maintenance signal. Treat it as reference design, not a supported library.
• You need JWT decoding or signature verification — pair it with (or replace it by) firebase/php-jwt, lcobucci/jwt, or web-token/jwt-framework.
• You need a maintained OIDC client: a full OIDC client library, a Laravel-native solution (Socialite plus a provider), or your IdP's official SDK will cover discovery, PKCE, token exchange, and rotation.
• You need modern PHP ergonomics. The 2016-era code predates typed properties, enums, and readonly; a hand-written claims class of comparable size is likely cheaper to own than to fork and modernize.
• You need active security response. There is no plausible patch cadence here; any CVE-adjacent issue becomes your team's problem.

Decision framing: run a short spike, then budget for fork-and-own. Adopt it if the cost of writing an equivalent typed claim set is higher than the cost of owning a fork — which, for a competent PHP team, it usually is not.

How to Pitch It (Stakeholders)

To executives: This is a small, free (MIT), well-shaped piece of plumbing for OpenID Connect identity claims, published years ago by a reputable PHP community org and essentially unmaintained since. It is not a strategic dependency. The right framing is a cheap evaluation of a build-vs-assemble decision for SSO, not a commitment to a vendor. Low cost, low lock-in, and a clear exit: we can replace it with roughly a week of in-house work if we ever need to.

To engineering: It is a claims DTO — typed accessors and required-claim validation for the OIDC ID token, with no transport, no crypto, and no framework coupling. The code surface is small enough to read in an afternoon and fork in a day. Expect to own it: pin it, vendor it, add tests around the claims you actually consume (iss, aud, exp, nonce, sub), and pair it with a real JWT library for decoding and signature checks. It buys us correctness in claim naming and shape, not maintenance or security response.

To security/compliance: It brings no dependencies, no network behavior, and no credential handling — it is a data shape, not an auth mechanism. The value is that claims become explicit and reviewable instead of loose arrays. The risk is that staleness reads as "abandoned" in a dependency audit; document the fork, the pin, and the internal owner before it appears on a scan.