SPAでの認証で、JWT(JSON Web Token)を採用するのは良い方法なのでしょうか？

Question

最近SPAアプリの勉強を始めて、ユーザー認証の方法として、JWT(JSON Web Token)があることを知りました。
1つチュートリアルをこなして感じたのですが、これって本当に良い方法なのでしょうか？

https://ja.wikipedia.org/wiki/JSON_Web_Token
そのチュートリアルは、上記の「使用」にあるような、Tokenを返してlocalStorageに保存させ、認証が必要な問い合わせには Authorization: Bearer <Token> ヘッダーを付けてリクエスト。サーバー側でTokenを判定する...。
という流れのものでしたので、王道的な方法なのだと思うのですが、私が疑問に感じたのは以下の点です。

1. 従来のような、Sessionを使った認証でも問題ないのでは？

ログイン時にSessionIDを払い出してlocalStorageに保存させ、認証が必要な時に独自ヘッダーなりでSessionIDを送りつけてサーバー側で照合すれば、従来のCookieを用いるような認証と同じことが実現できるんじゃないかと思ったのですが違うのでしょうか。

1. JWTでの認証メリット

仮に1番の内容が正しいとしたら、JWTでの認証をするメリットは何でしょうか？
Sessionを用いた方法だと、ファイルなりDBなりにSessionの中身（つまり認証情報）を保持することになるが、JWTではPAYLOADの中に認証情報を詰め込むからサーバーが保持しなくて良いから楽だ、みたいな話でしょうか。

1. JWT自体の安全性

https://jwt.io/
チュートリアルの中で上記URLに発行されたTokenをペーストして、「SIGNATUREを変えて見ましょう。自分がサーバーで設定した値にしないとTokenが一致しませんよね？」みたいなことをやっていたのですが、私が気になったのは「PAYLOADの中身丸見えじゃないか」ということです。
こんな簡単に中身が見えるものに認証情報を含めてしまって大丈夫なのでしょうか。

以上3点です。
よろしくお願いいたします。

合わせてついでに、と言っては失礼ですが、
0. Cookie & Session
0. JWT

この他に、ユーザー認証を実現する方法として何が考えられますか？
まずは自分で調べてみますので、キーワードだけでもご提示いただけたら幸いです。

Answer 1

以下はわたしの見聞にもとづく説明なので、間違っていたり不正確なところもあるかもしれません。

「従来のような、Sessionを使った認証でも問題ないのでは」についてですが、むしろセッションを使わないことが問題になりえます。

最近読んだ記事で次のものがよかったです。

• 海老原昂輔 (2018-09-21)「どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？」(「どうして JWT をセッションに使っちゃうわけ？」改題) [2019-03-31最終確認]

基本的に「セッション」といったとき、認証側で有効性をコントロールできないといけないはずです。だから、認証サーバにセッションストアを持っていなければならない。サーバのセッションストアから当該アカウントのセッション情報を削除すれば、そのセッションを即座に無効にできます。

しかしJWTの場合、サーバにセッションストアを持たないので、トークンが発行されてしまえばもうサーバのコントロールは利かない。いわば「投げっぱなしのセッション」なわけです (localStorageにセッション情報を保持しても解決にならないことはわかるとおもいます。トークンが署名や暗号によって改竄不能になっていても同じ)。上の記事の最大のポイントはこれだと思います。

対策としてすぐ思いつくのが、トークンの有効期限を短くすることで侵害による被害を最小限にすることです。しかし、短いといっても1分とかにしては使い物になりませんから限度があります。だいたい、それではセッションストアを用意して毎回セッションの有効性をチェックするのと大して違いません (というかより不便になります)。

詳しくは記事を読んで、末尾のフローチャートも見てください。

だから絶対だめだということではなく、きちんとリスクアセスメントをして使えばいいのです。次の記事では、実際のサービスにJWTを導入したときの検討内容を解説しています。

• じゅんいち☆かとう (2018-09-25)「JWT形式を採用したChatWorkのアクセストークンについて」[2019-03-31最終確認]

セッションに対するJWTのメリットについても軽く触れています。

---

また、ほかのアサーション型の認証方式もすべてだめかというとそんなことはなく、使いかた次第だと思います。自分の知っている例を書いておきます。

たとえばSAMLによるシングルサインオン (SSO) も、アサーション型の認証方式と言えると思います。アプリケーションのサービスプロバイダ (SP) がアイデンティティプロバイダ (IdP) に認証アサーションを投げることで認証し、属性アサーションを受け取ることでアカウントの属性 (メタデータ) を取得しそれをアプリケーションに渡します。
IdP (乃至はフェデレーション上の他のIdP) でアカウントが無効化 (永続的な無効化だけでなく、「ビジネスアワー以外はログインできない」といったものも含む) されても、それを即座に全てのSPに強制することはできません (プロダクトによってはそういう機能がありますが、標準化されたものではなく他プロダクトとの相互運用はできません)。

しかし、アカウントに対するサービスの認可 (authenticationではなくauthorizationのほう) は最終的にSPが責任を持つので、個々のサービスの利用に限ればSPでコントロールができます。SPはユーザのクライアントを従来型のセッションで管理することができます。その場合、SPでセッションタイムアウトを設けて、タイムアウトが近づいたらIdPに認証アサーションを投げ直すといった動作をすることで、セッション継続と同時にIdPでの失効に備えることもできます。

---

ほかにもっとうまく回答できるひとがいると思うので、わたしからの回答はこのくらいにしておきます。

Comments

[DecoratedKnight]

回答ありがとうございます。
>> サーバにセッションストアを持たないので、トークンが発行されてしまえばもうサーバのコントロールは利かない。
そう！そこも気になっていたんです。
ログアウト時にlocalStorageのデータを削除するようなプログラムを書いたとしても、ユーザーが事前にコピーしておけば利用できるのでは？ と思ったのですが、やはりその通りのようですね。
非常に参考になる記事の紹介もありがとうございます。
読み込ませてもらいます。