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

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

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

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

HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

JSON

JSON(JavaScript Object Notation)は軽量なデータ記述言語の1つである。構文はJavaScriptをベースとしていますが、JavaScriptに限定されたものではなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しが行えるように設計されています。

セッション

Sessionはクライアントがサーバに送ったすべてのリクエストのことを指します。

Authentication

Authentication(認証)は正当性を認証する為の工程です。ログイン処理等で使われます。

Q&A

解決済

1回答

2704閲覧

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

DecoratedKnight

総合スコア13

SPA(Single-page Application)

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

HTTP

HTTP(Hypertext Transfer Protocol)とはweb上でHTML等のコンテンツを交換するために使われるアプリケーション層の通信プロトコルです。

JSON

JSON(JavaScript Object Notation)は軽量なデータ記述言語の1つである。構文はJavaScriptをベースとしていますが、JavaScriptに限定されたものではなく、様々なソフトウェアやプログラミング言語間におけるデータの受け渡しが行えるように設計されています。

セッション

Sessionはクライアントがサーバに送ったすべてのリクエストのことを指します。

Authentication

Authentication(認証)は正当性を認証する為の工程です。ログイン処理等で使われます。

3グッド

7クリップ

投稿2019/03/31 01:54

編集2019/03/31 04:54

最近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

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

d0ne1s, nico25, qwertyuiop👍を押しています

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

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

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

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

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

guest

回答1

0

ベストアンサー

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

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

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

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

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

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

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

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

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


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

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

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


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

投稿2019/03/31 04:18

編集2019/03/31 11:11
ikedas

総合スコア4227

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

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

DecoratedKnight

2019/04/01 10:15

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問