SPAにおけるトークンベースのトークン管理について

Question

実現したいこと

SPAにログイン機能を実装する

前提

トークンベース認証とセッションベース認証について様々な意見を見た中で、SPAでは頻繁にAPIリクエストを送る関係でトークンベースが使われている（毎回認証が必要なくなる）という結論に達した。
そのため、JWTを使用して認証サーバーの構築を進めていきたい。

疑問

一般に
・アクセストークンは期限を短くする
・リフレッシュトークンは期限を長くする
したがって、アクセストークンの漏洩等のリスク低減になりうる。
という記事があり、それは理解できた。
ただ、ブラウザでセッションを管理するとなると現状CookieにhttpOnly属性をつけて保存するのがセキュリティ的にましだと考えたのですが、その方法だとどちらも毎回通信時にCookieを送る＝漏洩の危険性に関しては同等になりませんか？
リフレッシュトークンの運用方法についてはどのように実装すれば良いのでしょうか？

Answer 1

その方法だとどちらも毎回通信時にCookieを送る＝漏洩の危険性に関しては同等になりませんか？

はい。サーバとクライアントの間でトークンをやりとりするタイミングにおける危険性は、保存・交換手段が同じ手法であるとすれば、理論的には同等といえます。

ただし長期と短期を組み合わせることで、

• 同一のアクセストークンを継続して使い続ける場合の危険を減らし、
• 一方でアクセストークン更新時の通信経路・ユーザ認証周辺のコストを減らせる

というトレードオフ（リスクパフォーマンスの良さ）が、リフレッシュトークン/アクセストークンの思想です。

繰り返しになりますが、仮にアクセストークンと同じ手段を使用してやりとりする（例：CookieにhttpOnly属性をつけて保存）という前提であれば、リフレッシュトークンをやりとりするタイミングでのリスクは、アクセストークンをやりとりするタイミングにおけるリスクと理論的には同等です。

しかしこれは上記のメリットとのトレードオフです。リフレッシュトークンはアクセストークンに比べて、やり取りするタイミングの回数が相対的に少ないため、有効期限は相対的に長期に設定しても問題ない、という設計上の判断です。

Totalリスク ＝ [やりとり1回のタイミングにおけるリスク] × [やりとりの回数] × [更新間隔]

パフォーマンスを考慮して、Totalリスク を同等にしたい。
→[やりとり1回のタイミングにおけるリスク]が同じならば、
やり取りの回数が多いものは、更新間隔を狭め
やり取りの回数が少ないものは、更新間隔を広げる。

（もちろん、やり取りの回数が少ないものの更新間隔を、やり取りの回数が多いものと同じに設定すれば、TOTALリスクの合計は小さくできるが、それだと別のメリットが失われることになる）

リフレッシュトークンの運用方法についてはどのように実装すれば良いのでしょうか？

「HttpOnly属性は、JavaScriptからのアクセスを制限し、XSS攻撃によるトークンの盗難リスクを低減させるだけです。中間者攻撃のリスクを低減するため、HttpOnly属性だけでなくSecure属性も付けましょう」というのが教科書的な回答になるかと思います。
（「Secure属性」をお調べになれば、どういうことかお分かりになるかと思います）

Comments

[kuu13580]

丁寧な回答ありがとうございます。
Cookieは通信時に自動的に付与されるという認識なのですが別々のタイミングで送信できるのでしょうか？

[退会済みユーザー]

はい。アクセストークンに対応するクッキーとリフレッシュトークンに対応するクッキーは通常別々のタイミングで送信することができます。