質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.39%
SPA(Single-page Application)

SPA(Single-page Application)は、単一のWebページのみでコンテンツの切り替えができるWebアプリケーションもしくはWebサイトです。ブラウザでのページ遷移がないため、デスクトップアプリケーションのようなUXを提供します。

JWT(JSON Web Token)

JWT(JSON Web Token)とは、JSONをベースとしたアクセストークンの仕様。電子署名付きのURL safeなJSONのことを指します。電子署名が付いているため、改ざんをチェックできる点がメリットです。

Q&A

1回答

627閲覧

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

kuu13580

総合スコア11

SPA(Single-page Application)

SPA(Single-page Application)は、単一のWebページのみでコンテンツの切り替えができるWebアプリケーションもしくはWebサイトです。ブラウザでのページ遷移がないため、デスクトップアプリケーションのようなUXを提供します。

JWT(JSON Web Token)

JWT(JSON Web Token)とは、JSONをベースとしたアクセストークンの仕様。電子署名付きのURL safeなJSONのことを指します。電子署名が付いているため、改ざんをチェックできる点がメリットです。

0グッド

0クリップ

投稿2023/10/04 09:09

編集2023/10/04 09:10

実現したいこと

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

前提

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

疑問

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

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

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

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

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

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

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

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

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

Totalリスク = [やりとり1回のタイミングにおけるリスク] × [やりとりの回数] × [更新間隔] パフォーマンスを考慮して、Totalリスク を同等にしたい。 →[やりとり1回のタイミングにおけるリスク]が同じならば、 やり取りの回数が多いものは、更新間隔を狭め やり取りの回数が少ないものは、更新間隔を広げる。 (もちろん、やり取りの回数が少ないものの更新間隔を、やり取りの回数が多いものと同じに設定すれば、TOTALリスクの合計は小さくできるが、それだと別のメリットが失われることになる)

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

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

投稿2023/10/04 14:09

編集2023/10/04 14:23
退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

kuu13580

2023/10/04 15:35

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

退会済みユーザー

2023/10/04 16:20 編集

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.39%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問