The silent privilege-creep in three popular OIDC libraries — and why your staging cluster already leaked.

§1 · Context

OpenID Connect turned sixteen last year. The spec is finally boring — which
is a compliment — and yet the libraries most teams reach for keep finding
new ways to get it wrong. This is not an indictment of the spec. It is a
report on the state of its JavaScript implementations, measured against a
threat model any adversary can read in public.

We picked three libraries that between them account for roughly 71% of
weekly OIDC downloads on npm, as measured in the first quarter of 2026.
Two are maintained in earnest. One is maintained by a vendor whose
incentives are not aligned with yours, and the difference shows up in the
code.

"The defaults you ship are the threat model 95% of your users will ever
see." — Engineering folk wisdom, unattributed

§2 · Method & scope

For each library we performed: (a) a line-by-line read of the
authentication flow, (b) a differential run of our OAuth 2.1 compliance
corpus — 148 machine-checkable assertions lifted from RFCs 6749, 7636,
9126 and the OAuth 2.1 draft — and (c) a three-day fuzz of ID-token
handling using a deliberately misbehaving identity provider we maintain
for exactly this purpose.

We scored against six axes, with caps: auth correctness,
crypto correctness, supply-chain hygiene, documentation,
maintainer responsiveness, and default-safe ergonomics. A single
high finding caps at C. Two caps at D. A silent downgrade of a security
behaviour — as we will see in §3 — is an automatic F on that axis.

§3 · The at_hash regression

Of the three findings we rate high, this is the one that should embarrass
the most people. In auth0-spa-js v4.2 — released quietly on a Friday
in late February — the validation of the at_hash claim against the
access token was moved behind an opt-in flag. The changelog notes
"improved performance for token rotation." The diff removes a six-line
check.

// auth0-spa-js@4.1 (removed in 4.2)
if (idToken.at_hash) {
  const expected = base64url(
    sha256(accessToken).slice(0, 16)
  );
  if (expected !== idToken.at_hash) {
    throw new TokenValidationError('at_hash mismatch');
  }
}

We reproduced the practical impact: an attacker able to inject an access
token into a victim's SPA — via any of the usual XSS-adjacent primitives,
or a compromised CDN — can pair it with a legitimate ID token from a
concurrent sign-in and the library will accept the combination without
complaint. The access token need not even belong to the authenticated
subject. The check that prevents this is the one that was removed.

§4 · Refresh-token rotation, or the lack of it

passport-openidconnect has never rotated refresh tokens on its own. It
is a middleware; rotation is, defensibly, an application concern. But the
library's own documentation demonstrates refresh with a snippet that
stores the refresh token in a signed cookie and never rotates it. Every
real-world integration we audited — eleven of them, chosen from public
GitHub dependents by weekly-downloads — followed the snippet. None
rotated.

Rotation is in the OAuth 2.1 draft for a reason: a stolen refresh token
is a stolen session, forever, until the subject logs out. That "forever"
is measured in the months you will take to notice.

§5 · PKCE, mis-applied

PKCE is not optional in 2026. Two of the three libraries do the right
thing and enforce it on public clients. passport-openidconnect accepts
any code_challenge_method the provider responds with — including the
string "plain", which defeats the entire point of PKCE and is forbidden
by RFC 7636 §4.3 for anything that calls itself a security control.

§6 · What to do on Monday

1. If you are on auth0-spa-js ≥ 4.2, set validateAtHash: true today.
   Consider pinning to 4.1 until the default is restored.
2. If you use passport-openidconnect, audit your refresh-token storage.
   Rotate on every use. Revoke on logout. Log rotation failures.
3. Pin PKCE to S256 at the client level. Do not trust the provider to
   negotiate it for you.
4. Subscribe to the re-audit feed for these packages. We will re-grade
   when the defaults change — not when the PR lands.

§7 · Maintainer responses

We sent drafts to all three projects on apr 11, with 10-day response
windows. openid-client replied within 36 hours, accepted the
documentation findings, and shipped clarifying docs before publication.
passport-openidconnect acknowledged receipt and committed to a
rotation example in the README. auth0-spa-js did not respond.