リフレッシュのレスポンスを取りこぼしても、直前の refresh token が「置換トークンを使い始めるまで」生き残る。60 分の猶予枠に間に合わなかったアプリが、マーチャントの再インストール無しで自力復帰できるようになった。移行作業は不要。
refresh token を使った後、その同じトークンで再試行できるのは 最大 60 分。その窓を過ぎると、保存済みの古い refresh token はもう使えなかった。応答を取りこぼしたアプリはそこで詰む。
保存済みの古い refresh token は、アプリが置換 refresh token を使い始めるまで再試行できる。時計ではなく「アプリの状態」が期限になった。
| 項目 | これまで | これから |
|---|---|---|
| 旧 refresh token の再試行可否 | 最大 60 分 使用後、一定時間だけ再試行可 | 置換を使うまで 時間ではなく状態で判定 |
| 応答ロスト時の挙動 | 窓を過ぎると旧トークンが使用不可 → 復旧手段なし | 保存済みの旧トークンで再試行し、新ペアを取り直せる |
| マーチャントの操作 | アプリを開き直してもらう必要があった | 不要 アプリ側だけで復帰できる |
| 旧トークンが retire されるタイミング | 時間経過 | アプリが置換 refresh token を使用した時点 |
| 導入に必要な作業 | — | なし API バージョン更新・設定変更・opt-in 不要 |
| トークン全体の寿命 | — | 通常の 90 日 を超えて延長されることはない |
アプリが置換 refresh token を使った瞬間、直前のトークンは retire される。つまり「復旧経路が閉じるトリガーはアプリ自身の行動」。
復旧期間は、元の refresh token の初回使用から 30 日まで。放置し続けて無限に古いトークンが生き残るわけではない。
refresh token 本来の寿命は 90 日のまま。今回の変更でトークンが延命されることはない。
自動的に新しい挙動が適用される。新しい API バージョン・設定変更・opt-in はいずれも不要。
影響なし。記事中でもそれ以上の言及は無い。
すでに有効期限付きオフラインアクセストークンを使っているなら、マイグレーションは不要。以下は「引き続き守るべきこと」として明示されている 4 点。
リフレッシュ操作は shop ごとに serialize する。並行リフレッシュを走らせない。
返ってきた access token と refresh token をひとつのトランザクションで永続化する。
以降のリフレッシュには 最新の refresh token を使う。古い方を通常運用に混ぜない。
置換トークンを保存済みなのに古いトークンを使い続ける理由にはしない。非常口であって常用ドアではない。
旧挙動は使用後 60 分の時間窓。新挙動は「置換トークンをアプリが使い始めたら旧トークンを retire」。テストやリトライ設計で 時計を前提にした assumption があるなら見直しどころ。
プラットフォーム側が復旧経路を用意しただけで、access token と refresh token をペアで書く実装義務は変わらない。片方だけ書ける経路が残っていると、復旧経路を使う前提の状態管理が崩れる。
「ショップごとにリフレッシュを serialize せよ」が明記されている。複数ワーカーが同時にリフレッシュを叩く構成だと、どのトークンが最新かの判定が壊れる。分散ロックやキューでの排他は引き続き必要。
復旧できるのは元の refresh token の初回使用から 30 日以内。通常の 90 日寿命も延びない。「壊れたまま数か月放置したストア」は依然として救えないので、リフレッシュ失敗の検知・アラートは必要。
新 API バージョン・設定変更・opt-in がいずれも不要なので、何もしなくても恩恵は受けられる。一方で告知の「continue to」リストは、既存実装の監査項目そのもの（shop 単位の直列化 / ペアのアトミック保存 / 最新トークン使用 / 復旧経路の常用禁止）。この 4 点を満たしているかのチェックは今やる価値がある。