Openid Connect Claims Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, single-responsibility library: a claims-set value object and validator for OpenID Connect ID Tokens. It is a component, not an integration. A Laravel application still needs discovery document handling, JWKS retrieval and caching, signature/algorithm verification, token endpoint client, nonce and session state, and key rotation. The package can only sit at the innermost layer of an auth flow that something else must already have built.

Integration feasibility. Plain Composer library with no Laravel service provider, facade, config, or publishable assets. Instantiation is manual, which is acceptable for a leaf dependency but means all glue code is yours. The 2016 release date is the practical blocker: constraint sets from that era (PHP >=5.6/^7.0, old league/* and PHPUnit pins) frequently collide with Laravel 10/11 and PHP 8.1+. Expect composer why-not conflicts and possible runtime deprecations; a fork with widened constraints is likely required before it will even install cleanly in a modern stack.

Technical risk. High for its size, because it touches a security-critical surface. Unmaintained since May 2016, one release, 16 stars, zero dependents — no ecosystem validation and no CVE response path. Correctness against current OIDC Core requirements is unproven: audience matching with multiple aud values, mandatory azp checks, exp/iat clock skew, nonce replay, auth_time and acr/amr semantics, and at_hash/c_hash binding are all areas where 2016-era implementations were commonly incomplete. It almost certainly does not verify signatures, so a false sense of security is the main hazard.

Key questions.

• Which claims are actually enforced versus merely stored, and are aud/azp/nonce/exp validated with configurable skew?
• Does it assume signature verification happened upstream, and is that documented?
• What are the transitive dependencies, their licenses, and their PHP 8 compatibility?
• Is there a maintained fork or a drop-in replacement with equivalent semantics?
• Can the same logic be expressed in ~150 lines internally, removing the dependency entirely?
• Who owns the fork and the security review if we adopt?

Integration Approach

Stack fit. Language-level compatible, framework-agnostic. Treat it as a leaf dependency behind an internal IdTokenClaimsValidator interface so vendor classes never leak into controllers, middleware, or Socialite callbacks. Laravel's container can bind the implementation, but the package itself provides nothing to wire.

Migration path. If already present, pin the exact version, vendor-fork it under the organisation namespace, and add contract tests built from OIDC Core test vectors before any upgrade. Plan replacement with the claim-validation layer of lcobucci/jwt or web-token/jwt-framework, which are maintained and cover signature verification too. For greenfield work, the recommendation is not to adopt: the validated surface is small enough to implement internally or delegate to a maintained JWT library.

Compatibility. Verify under PHP 8.1, 8.2, and 8.3 before committing. Check that its league/* and PHPUnit constraints do not block composer update for Socialite, Passport, or other League packages. Autoloading under Laravel 10/11 is fine; the risk is dependency resolution and deprecation noise, not PSR-4.

Sequencing.

1. Timeboxed spike: install on the target PHP version, enumerate exactly which claims are checked, and diff against OIDC Core.
2. Decide fork-versus-replace; if retained, fork, widen constraints, and add the nonce, azp, multi-audience, and clock-skew checks the package omits.
3. Wrap behind the internal interface with contract tests in CI.
4. Schedule absorption into the internal auth module or migration to a maintained JWT library within one or two quarters; do not let the fork become permanent by default.

Operational Impact

Maintenance. Effectively zero upstream activity and no security process. The realistic operating model is "we own this code now." The fork is small, so the ongoing cost is low in hours but permanent, and it lands on whoever owns identity.

Support. GitHub issues only, no SLA, no maintainer responsiveness guarantee. Internal OIDC expertise becomes the de facto support channel, which concentrates risk in one or two engineers.

Scaling. Technically negligible: stateless pure-PHP claim checks with no I/O, no measurable throughput cost. The scaling concern is organisational — knowledge concentration and a growing fork divergence from upstream — not compute or latency.

Failure modes.

• Silent acceptance of a token with the wrong audience or missing azp, enabling token substitution or mix-up attacks.
• Replay because nonce is stored but not validated against session state.
• Boundary failures around exp/iat with no skew allowance, causing intermittent auth outages at clock drift.
• Optional claims absent and treated as passes rather than failures.
• CI breakage when a PHP upgrade or a composer update makes the 2016 constraints unresolvable, blocking unrelated releases.

Ramp-up. The code itself is readable in an hour and a mid-level engineer can integrate it in a day. The danger is that integration is easy while correct validation is hard: an engineer without OIDC literacy will not notice the gaps. Budget a security review and a spec walkthrough as part of onboarding to this dependency.