Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

clerk-js: SessionTokenCache serves server-expired session tokens when the device clock runs behind (regression of #672)

オープン
  • 何か問題がありますか？
#10,185 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
express, javascript, react-native, typescript
領域
authentication

調査の方向性

Start in packages/clerk-js/src/core/tokenCache.ts, where get() (around line 194) computes remaining TTL against createdAt, and where createdAt is set from the server iat (around line 411). Run packages/clerk-js/src/core/__tests__/tokenCache.test.ts with the gist's skew test added to see it fail. Done means the skew test passes, the existing broadcast resilience test still passes, and the design choice for measuring the clock offset is agreed in the thread.

索引モデルが issue の本文から書いたものです。

説明

Preliminary Checks
  • I have reviewed the documentation: https://clerk.com/docs
  • I have searched for existing issues: https://github.com/clerk/javascript/issues
  • I have not already reached out to Clerk support via email or Discord
  • This issue is not a question, general help request, or anything other than a bug report directly related to Clerk.
Reproduction

https://gist.github.com/AKhozya/06c6aab6ed3416e50fc8227823ac0a6c

Publishable key

Not included: the bug is in clerk-js's token cache and does not depend on an instance. Happy to share one if it helps.

Description

If the device clock runs behind the server, SessionTokenCache.get() keeps returning a session token after the token has expired by server time. Once the token is more than 5 s past exp, the backend's default allowance (DEFAULT_CLOCK_SKEW_IN_MS, packages/backend/src/jwt/verifyJwt.ts:20) rejects it.

Cause. When a token resolves, tokenCache.ts:411 sets live.createdAt = issuedAt, the JWT iat in server time. get() (line 194) computes elapsed = deviceNow - createdAt, so remainingTtl = (exp - iat) - (deviceNow - iat) = exp - deviceNow. That compares server time with device time directly. If the device runs S seconds behind, the cache serves the token for S seconds after it expired. The deletion timer (line 409, expiresAt - deviceNow) fires S seconds late as well.

History.

PR Merged Change to tokenCache.ts
#672 2023-01-27 "Account for user clock skew in TokenCache": createdAt from the device clock at caching time, so elapsed time is measured on one clock
#7317 2026-01-30 "Proactive session token refresh": value.createdAt = issuedAt
#9030 2026-07-03 keeps it as live.createdAt = issuedAt

protectSession.ts:291 already describes this hazard for another store and avoids it by measuring elapsed time on one clock.

Steps to reproduce: apply the test from the gist to packages/clerk-js/src/core/__tests__/tokenCache.test.ts on main 44b09ba and run that file.

  1. The server issues a token at T with a 60 s lifetime.
  2. The device clock reads T − 40 when the token is cached.
  3. Advance 50 s: get() returns the token (correct, 10 s remain).
  4. Advance 20 s more: by server time the token expired 10 s ago.

Expected behavior: at step 4, get() returns undefined, as it does in the control test with no skew.

Actual behavior: at step 4, get() still returns the token. Result: Tests 1 failed | 69 passed (70); only the skew test fails.

Effect in an app. Our Expo app sends the session token to our own Express backend, which calls verifyToken and answers a failed verification with 401.

Emulator clock Chat sends that failed
36 s behind the host about 5 of 15, each with the app's error for an HTTP 4xx other than 429 (status not captured)
resynced to the host 0 of 10

Our workaround, not yet deployed: clockSkewInMs: 60_000 on verifyToken, and one retry with getToken({ skipCache: true }) after a 401.

On a fix. If createdAt takes the device clock when the token resolves, the new test passes. #672 uses the device clock at caching time. If a token is already partway through its lifetime when it reaches the cache, get() counts its full lifetime from that moment. If the clocks agree, the deletion timer (exp minus device time) still evicts such a token at its real expiry, so get() serves it late only if that timer runs late. It also fails one existing test, broadcast resilience > a failing postMessage does not evict the freshly cached token, because that test's fixture has iat after exp. A fix that handles both a device clock running behind and a token that reaches the cache partway through its lifetime may need the offset between the server clock and the device clock, for example measured when a token is freshly minted. We have not tested such a fix.

Environment
Item Value
@clerk/expo 4.6.9
@clerk/clerk-js installed 6.33.0; its built bundle sets the cache entry's createdAt to the token's iat
clerk/javascript commit tested main 44b09ba
Expo SDK 57
React Native 0.86.3
Device Android emulator, system image android-37.1
主要言語
TypeScript
スター
1.8k
フォーク
479
平均マージ
1日 18時間
マージ済み PR（30日）
313

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

clerk/javascript のほかの issue

clerk/javascript の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。