SPA での認証方法に関する マサカリぶん投げ会場はこちらです ->

SPA での認証はどうしてますか？

Session-Based authentication cookie にsessionID を保存する sessionID をキーにして、情報はサーバー側に保存 従来のモノリシックなアプリケーションで利用 Token-Based authentication いわゆるJWT のようなtoken を使った方式 どこにセッション情報を持たせるかは自由（要件次第）

JWT (JSON Web Token) とは JOSE (Javascript Object Signing and Encryption) の規格の一つ。 JOSE は安全にやり取りを行う必要がある情報をJSON で取り扱うため のフレームワークで、以前はこういった情報がASN.1 やXML として取 り扱われていた。 JWT は対象のデータについて、完全性の担保を行う場合はJWS (JSON Web Signature) に、暗号化を行う場合はJWE (JSON Web Encryption) に基づいている。 （必ずしも完全性の担保や暗号化が行われている訳ではない）

ここから仮想ディベート （実在する人物の見解とは異なります）

Session-Based 派 token をlocalStorage に保存するとXSS 脆弱性が存在する場合に盗ま れる token の有効期限が来るまで無効化できない 対策としてログアウトするときにtoken を無効化（ブラックリス トに追加）させる処理が必要 パスワードを変えたときにtoken も再発行しなければならない セキュリティリスクを増やす上に手間もかかるので意味がない

Token-Based 派 API サーバをステートレスにできるのでスケールアウトが楽 毎回sessionID からDB 参照しなくて良いのでパフォーマンス高い そもそもXSS 脆弱性が存在することが問題では？ XSS 脆弱性があるならそれはtoken 云々の話ではない XSS が怖いのならlocalStorage じゃなくてCookie のHttpOnly 属性で 制御すれば良い トークンの有効期間を短くすれば漏洩した場合のリスクを抑えられ る

Session-Based 派 スケールアウトのことを考えるなら、セッション情報をインメモリ ではなく独立したストレージで管理すればいい話 Third-party software を利用している限りXSS 脆弱性のリスクは存在 する そもそもHttpOnly はJS で直接cookie を取得できないようにするだけ トークンの有効期限が切れるたびにログインしなければならない

Token-Based 派 だからサーバーでセッション管理したくないって言ってんだろ リスクを最小限に抑えた上でそれに見合う利便性が得られるという 話をしている リフレッシュトークンを使ってtoken の再発行ができる仕組み (Sliding Sessions) をつくれば良い

収拾がつきません

仮想ディベートはここまで 以下、個人の見解

session とtoken のどちらで認証すべきか？ 要件次第。 センシティブな情報をクライアント側で管理すべきではないが、「セ ンシティブな情報」の定義と、その情報にリスクを課した場合に開 発・メンテナンスの労力がどれだけ下がるかによる。 完全にRestful なAPI サーバー（外部クライアントへの提供・micro service など）であればセッション管理を行う必要がないため、token が適している。

token はlocalStorage に格納して良い？ 知られて困る情報でなければどうでも良い。 XSS 脆弱性が存在する限り、localStorage でもcookie でもそんなにリス クは変わらない認識。 そもそもcookie に保存するのであればSession-Based と比較して大し たメリットがないし、むしろサーバーサイドの実装コストが重そう。 auth0 を利用すれば、localStorage にもcookie にも保存しない方法でリ スクを最小限に抑える実装ができる。ただし、ユーザがThird-Party cookie をブロックした状態だと問題が出る。

token でセッション管理して良い？ 見られて困る情報 ... 以下略 ただし、ほとんどの場合は何かしら重要な情報をサーバー側で持たせ る必要があると思うので、サーバー側に管理責任を負わせるのが筋な 気がする。 ついでにクライアント側で管理する場合は文字数制限に注意する必要 がある。

token の有効期限はどれくらいにすべき？ 要件次第だが、基本的には短くする（1 分〜10 分とか）。 期限切れのたびにログインし直すのはユーザーに優しくないので、 OAuth で言うところの、有効期限を長く取ったリフレッシュトークン を併用する。 この場合、『token 』の役割はアクセストークンと呼ばれるものにな る。

アクセストークンの期間を短くしてもリフレッ シュトークンが漏れたら意味なくない？ はい。 なので漏洩が判明した場合、該当のリフレッシュトークンをブラック リストに入れる必要がある。 Session-Based でやっているように、サーバーサイドのログアウト時 に

じゃあリフレッシュトークンを使わずにtoken の有効期限を長くするのと変わらないのでは？ token をブラックリストに入れるシステムの場合、アクセスするたび にブラックリストDB を参照する必要があるため、リフレッシュトーク ンが存在することでサーバー負荷を減らすことができる。 サーバー負荷軽減の代わりにリスクを無視しているとも言えるが、や はり要件次第。 また、ユーザーを強制的にログアウトさせたい場合はアクセストーク ンの有効期限を極端に短くすることで実現できる。

結論 「楽だからJWT 」はなし（そもそも楽ではない場合が多い） 認証を外部サービスに頼る理由でのToken-Based はあり ノウハウがなくても使えるライブラリやサービスを使う（それでも 適切な知識は必須） モバイルアプリのようなCookie の使えないプラットフォームや、マ イクロサービスのような完全ステートレスであればToken-Based が 良さそう token としてsessionID を持ち、サーバーで管理することでJWT の機 能を使ったセッション管理というハイブリッド手法もある（あるの か？）

参考 JWT ハンドブック 情報セキュリティ技術動向調査（2011 年下期）：IPA 独立行政法 人 情報処理推進機構 Javascript Object Signing and Encryption (JOSE) — jose 0.1 documentation RFC 8725: JSON Web Token Best Current Practices Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)

どうしてリスクアセスメントせずに JWT をセッションに使っちゃ うわけ？ - co3k.org HTML5 のLocal Storage を使ってはいけない（翻訳）｜TechRacho （テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS 株式 会社 JWT でセッション管理してはいけない - Qiita そもそもJWT に関する私の理解は完全に間違っていた！ - ブログな んだよもん SPA+SSR+API で構成したWeb アプリケーションのセッション管理 - ペパボテックブログ

JWT 認証、便利やん？ - ブログ JWT 形式を採用したChatWork のアクセストークンについて - Chatwork Creator's Note JWT を使った今どきのSPA の認証について 認証用トークン保存先の第4 選択肢としての「Auth0 」 - ログミー Tech

Refresh Token Rotation Authentication - Password & user management - Amplify Docs セキュリティ視点からの JWT 入門 - blog of morioka12 Cookie - JWT などのToken をlocalstrage(HTML5 の) に保管すること について｜teratail クロスサイトスクリプティング(XSS) 対策としてCookie のHttpOnly 属性でどこまで安全になるのか - YouTube

徳丸 浩さんはTwitter を使っています 「そもそもJWT をセッション 管理に使うと、ログアウト時にセッション情報を破棄できず… 続き は質問箱へ #Peing # 質問箱 https://t.co/St1Cggr2j2 」 / Twitter Auth0 のSilent Authentication ( サイレント認証) とRefresh Token Rotation ( リフレッシュトークンローテーション) を完全に理解した ( い) - 一から勉強させてください Refresh Token ： どのような場合に使用し、どのように JWT と相互 作用するか 2020 年版 チーム内勉強会資料その1 : JSON Web Token - r-weblife "JWT= ステートレス" から一歩踏み出すための考え方