Identity Link Shared Laravel Package

Product Decisions This Supports

• Multi-audience token validation (1.1.0) unlocks a single auth path for multiple clients instead of per-client issuers or bespoke middleware. Concretely, it supports:
  • One API serving web, mobile, and partner/BFF clients whose tokens carry different aud values.
  • Multi-tenant or multi-brand products where each tenant gets its own audience but shares one deployment.
  • Staged migrations (e.g., api-v1 alongside api-v2) without issuing parallel token types or dual-running validators.
  • Service-to-service calls where a downstream service is added to an existing token's audience list rather than re-issuing credentials.
• Roadmap impact is modest but real: "any configured audience matches" is an OR semantic. It removes a common reason to build a custom validation layer, so any roadmap item described as "support a second client type" or "add a partner integration" can now be scoped without auth work.
• Build vs. buy: the decision to adopt a package for JWT validation was never really about parsing tokens — it was about owning security-sensitive comparison logic and keeping up with CVEs. This release argues for buy: the maintainers shipped a dependency-level security fix within the release cadence, which is work you would otherwise own.
• Configuration risk to manage, not a blocker: widening from one audience to a list increases the blast radius of a misconfiguration (an over-broad list silently accepts tokens meant for another service). Treat the audience list as production config with review, and keep it minimal per environment.
• Security maintenance cost: the CVE-2026-108082 fix lands via a bump to symfony/http-foundation 6.4.48. The practical PM decision is a routine dependency-hygiene ticket, not a feature — but it is a forcing function to confirm your own lock file resolves to a patched version and that your version constraints don't pin you below it.

When to Consider This Package

Consider adoption when:

• You issue or validate JWTs and need more than a single hard-coded audience — multiple client types, tenants, or an in-flight API version migration.
• You want audience validation to be a configuration concern rather than code you maintain and review internally.
• Your application serves HTTP responses through symfony/http-foundation and therefore inherits the HeaderUtils::split() ReDoS surface that 1.1.0 patches; staying current is the cheap path.
• You are on a supported http-foundation line (6.4.x here) and can absorb a patch-level dependency bump.

Look elsewhere when:

• Your tokens are opaque/session-based, or your auth is delegated entirely to an external IdP that already enforces audience at the edge — you'd be adding a second, redundant check.
• You need audience intersection semantics (token must match all of a set), wildcard audiences, or per-audience claim requirements. This release is explicitly "any match," and nothing here suggests wildcards are supported.
• You must stay on an older http-foundation branch (5.4, or 6.0–6.3) — the security fix as described targets 6.4.48, so verify patched equivalents or expect to be exposed.
• Your threat model requires you to patch faster than the package's release cadence, or you cannot tolerate a third-party dependency in the auth path.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release with one useful capability and one security fix. The capability — accepting several token audiences — means we can add a new client type or onboard a partner without building separate authentication plumbing, which shortens those roadmap items. The security fix addresses a denial-of-service flaw that arrives through a shared HTTP library rather than this package's own code; upgrading is low effort and is the responsible default. Neither change alters our architecture or forces a migration. Recommendation: upgrade in the normal maintenance window, and treat the audience configuration as reviewed production config rather than something set once and forgotten.

For engineering: 1.1.0 adds list-based audience validation using OR semantics — a token is accepted if any aud value matches any configured audience. Confirm the config shape (single value vs. array), and make sure each environment's list contains only audiences that environment should accept. The release also carries CVE-2026-108082, a ReDoS in HeaderUtils::split() reachable via the Cache-Control request header, resolved by moving the lock file to symfony/http-foundation 6.4.48. Check that our constraints permit ≥6.4.48 and that our own lock file resolves there — the bundle's lock file being patched does not guarantee ours is. No breaking changes or deprecations are described, but no compatibility statement is included either; run the auth test suite against the new version before rollout.