nbf claim is validated in Ruby only, ignored by Python, PHP and Node

[andrevanzuydam]

Summary

Ruby issues and validates the JWT nbf (not before) claim. Python, PHP and Node ignore it. The same token, with the same secret, gets two different answers depending on which framework verifies it.

Where

Ruby, which is the correct one:

# lib/tina4/auth.rb:163  (issues it)
"nbf" => now

# lib/tina4/auth.rb:149  (validates it)
return nil if payload["nbf"] && now < payload["nbf"]

Python (tina4_python/auth/__init__.py, valid_token), PHP (Tina4/Auth.php) and Node (packages/core/src/auth.ts, validToken) validate the signature and exp only. None reference nbf.

Verified by reading all four implementations in source.

Reproduction

Mint a token with an nbf set a minute in the future, then verify it in each framework.

• Ruby: rejected, correctly, until nbf passes
• Python, PHP, Node: accepted immediately

Why it matters

A token intended to become valid later is live immediately on three of the four frameworks. In a mixed-language estate the authentication decision depends on which service received the request, which is not a property anybody wants in an auth path.

nbf is a registered claim in RFC 7519 section 4.1.5. A verifier handed a claim it understands and then ignoring it is not doing what the caller expected.

Ruby already issues nbf on every token it mints, so tokens carrying the claim exist in the wild today.

Suggested fix

Python is master, so the decision gets made there first. Validating nbf in all four is the correct call, given Ruby already issues it.

The alternative, dropping nbf from Ruby's issuer, throws away a working RFC-conformant check to reach parity downward. Not recommended.

Needs the fix plus a named regression test in all four, positive and negative: a token with a past nbf accepted, a token with a future nbf rejected.

Found by

Auditing Auth across all four frameworks while grounding a course module on authentication. No fix applied.

[andrevanzuydam]

Fixed in 3.13.92 (all four frameworks).

Decision recorded: Ruby was right to validate nbf, wrong to stamp it. All four now honour the claim on validation, with 60 seconds of clock-skew tolerance (now + leeway < nbf) so a token minted on another host is not rejected over a one-second difference. A token carrying no nbf stays unconstrained, which keeps every token already in circulation working.

get_token never stamps an nbf. Ruby's auto-stamp is removed -- breaking and deliberate: a library silently post-dating tokens is surprising, and it made Ruby the lone outlier among the four. A caller wanting a post-dated token puts its own nbf in the payload.

Also fixed along the way: algorithm pinning. valid_token now rejects a token whose header alg disagrees with the configured algorithm (including alg: "none") before doing any signature work. To be precise about what this is and is not: it was not exploitable in any of the four. None of them read header.alg to choose a verifier, so a token minted for another algorithm produced a different signature and was already rejected, and rewriting a real token's header invalidates its signature because the header is part of the signing input. What pinning buys is early rejection, cross-framework parity, and a regression lock against a future refactor that decides to trust the header.