Dual JWT Authentication: Security, Redis, and Trade-Offs
Comments on “Dual JWT Authentication: Security, Redis, and Trade-Offs”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
JSTools.Space describes a Dual JWT design: access tokens of 5–15 minutes kept in memory, refresh tokens of up to 30 days in HttpOnly cookies, and a per-user Redis revocation cutoff that invalidates all older refresh tokens at once. The article stresses the trade-offs. Renewing without invalidating old tokens is not replay-resistant rotation, which RFC 9700 expects of public clients. The cutoff cannot end a single device's session, and access tokens may work about five minutes after logout-all. The performance savings are asserted, not measured.
Why it ranked
No. 17 of 51 with a score of 0.64. The panel rated it highest on technical depth (0.85) and practical relevance (0.83), lowest on significance (0.48). The judges disagreed most on new information (spread 0.58), so the story is marked contested. Placed No. 17, No. 12 by score alone: the sixth Security story of the day (−0.060). The placement terms move stories; they are not part of the score.
- AI judgeJudge 2claude-haiku-5-5
- Technically substantive, practical authentication architecture guide with Node.js examples and security trade-off analysis, though largely tutorial-style with well-known ideas and some unsupported assertions.
- AI judgeJudge 3gpt-5.6-luna
- A technically detailed authentication tutorial with concrete Node.js, JWT, cookie, Redis, revocation, CSRF, and OAuth trade-offs. It is useful and well-supported conceptually, though not novel research or a major new development.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.64total under rubric v2.3Contestedjudges differ by 0.58 on new information
- Significance0.48
- Reader interest0.68
- Audience breadth0.65
- Practical relevance0.83
- Substantiated0.62
- Technical depth0.85
- New information0.73
- Counts against: Promotional0.05
- Counts against: Overclaim0.14
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.61 | 0.30 | 0.52 | 0.48 | 0.32 | +0.24 | +0.115 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.76 | 0.55 | 0.72 | 0.68 | 0.21 | +0.26 | +0.176 |
| Audience breadthHow many people who build technology does it concern? | 0.77 | 0.60 | 0.58 | 0.65 | 0.19 | +0.13 | +0.084 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.96 | 0.70 | 0.82 | 0.83 | 0.26 | +0.22 | +0.182 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.62 | 0.45 | 0.78 | 0.62 | 0.33 | +0.05 | +0.031 |
| Technical depthHow technically substantive is it? | 1.00 | 0.70 | 0.86 | 0.85 | 0.30 | +0.05 | +0.043 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.91 | 0.35 | 0.93 | 0.73 | 0.58 , above the contested threshold | +0.05 | +0.036 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.04 | 0.10 | 0.01 | 0.05 | 0.09 | −0.19 | −0.010 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.15 | 0.20 | 0.08 | 0.14 | 0.12 | −0.11 | −0.016 |
| Sum of contributions | +0.642 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.642 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-08/17/"><img src="https://rubric.hrih.si/badge/2026-11-08/17.svg" alt="Ranked #17 on Rubric, 8 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 8 no source given. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenQuote
RFC 9700 (OAuth 2.0 Security Best Current Practice) requires public clients to use sender-constrained refresh tokens or refresh-token rotation with replay detection.
The article gives no link or citation for it.
The article says “OAuth 2.0 Security Best Current Practice, defined in RFC 9700, requires public clients to use sender-constrained refresh tokens or refresh-token rotation with replay detection”
The source says No source to compare with.
No source givenCausal conclusion
In the stateless Dual JWT design, issuing a new refresh JWT without invalidating the previous one is token renewal, not replay-resistant rotation, so several refresh tokens from one session can be valid simultaneously.
The article gives no link or citation for it.
The article says “Issuing a new refresh JWT without invalidating the previous one is token renewal, not replay-resistant refresh-token rotation”
The source says No source to compare with.
No source givenNumber
After a logout-all with a 5-minute access token lifetime, existing access tokens may keep working for up to approximately five minutes.
The article gives no link or citation for it.
The article says “When the user selects logout-all, existing access tokens may continue working for up to approximately five minutes”
The source says No source to compare with.
No source givenNumber
The article's access-token design uses a lifetime of 5–15 minutes and refresh tokens last up to 30 days.
The article gives no link or citation for it.
The article says “Lifetime 5–15 minutes Up to 30 days”
The source says No source to compare with.
No source givenCausal conclusion
A per-user Redis revocation cutoff lets the system invalidate all older refresh tokens of a user with a single state update, but cannot selectively invalidate one device.
The article gives no link or citation for it.
The article says “This allows the system to invalidate all older refresh tokens belonging to a user with a single logical state update”
The source says No source to compare with.
No source givenCausal conclusion
Deleting or clearing the refresh cookie on the client does not invalidate the underlying JWT on the server, so a copied refresh token may remain usable.
The article gives no link or citation for it.
The article says “But deleting a cookie doesn’t invalidate the underlying JWT on the server”
The source says No source to compare with.
No source givenGeneralization
SameSite distinguishes sites rather than origins, so applications sharing a registrable domain across subdomains must consider same-site, cross-origin attacks.
The article gives no link or citation for it.
The article says “SameSite distinguishes sites rather than origins. Applications sharing a registrable domain across multiple subdomains must consider same-site, cross-origin attacks”
The source says No source to compare with.
No source givenGeneralization
Stateless access tokens combined with stateful refresh-token rotation may be the strongest practical compromise for many production applications.
The article gives no link or citation for it.
The article says “For many production applications, the strongest practical compromise may be stateless access tokens combined with stateful refresh-token rotation”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 1 pts, not on front page
Recorded for context only, checked 8 Nov 2026, 05:46 UTC. It played no part in the ranking.