トークン認証（JWT）について

Question

APIのアプケーションを作るときに、Authorizationのheaderに認証トークン（アクセストークン）を載せてAPIを叩くことについては知っているのですが、API側で認証トークンを更新したときに認証トークンをクライアントサイドに返すときはAPIのレスポンスに含めて返しても問題ないか知りたいです。

Comments

[退会済みユーザー]

トークンを持たないもしくは期限切れのユーザーがアクセスしてきたら、再度ログインしてもらってトークンを再発行するのが良いと思いますけど、そうしない事情があるのですか？

[nanase21]

期限期間内にアクセスしてきたユーザーを想定しており、認証トークンをよりセキュアにするためにAPIを呼び出すたびに認証トークンを更新したいと思い質問させて頂きました。
その際に更新した認証トークンをresponseのheaderに載せて返すべきか、そのままJSONで返してもよいかについて質問させて頂いた次第です。
ご指摘内容を考えると、都度更新しなくてもセキュリティはそれなりに担保されるという背景でご指摘を頂いたのでしょうか？

[退会済みユーザー]

質問者さん、無言ですが、放置しないでクローズしてください。不明点などあればそれを書いてください。とにかく無言で放置は NG です。

[nanase21]

すいませんでした。今後は気をつけるようにいたします。

Answer 1

コメント欄のこちらに回答します。

期限期間内にアクセスしてきたユーザーを想定しており、認証トークンをよりセキュアにするためにAPIを呼び出すたびに認証トークンを更新したいと思い質問させて頂きました。

APIを呼び出すたびに認証トークンを更新する、ということは、古いトークンは無効にするという意味だと解釈しました。
この実装だと、なんらかの理由（例えばネットワークの不調）でレスポンスを取りこぼした際に、認証状態が維持されなくなります。再度認証すればよいのですが、そこまでのセキュリティが必要なのでしょうか?

一般的には、「APIを呼び出すたびに認証トークンを更新する」ことはしないと思いますし、そこまでしなければならない理由があるのであれば、その理由を含めて質問いただかないと、回答は難しいと思います。

その際に更新した認証トークンをresponseのheaderに載せて返すべきか、そのままJSONで返してもよいかについて質問させて頂いた次第です。

これはどちらでもあまり変わらないと思います。なぜなら、様々な脅威について、攻撃者が「レスポンスボディなら読めるがレスポンスヘッダは読めない」という状況が考えにくいからです。特定の脅威を想定しているのであれば、その脅威を教えていただかないと回答できないです。

Comments

[nanase21]

> APIを呼び出すたびに認証トークンを更新する、ということは、古いトークンは無効にするという意味だと解釈しました。
ご認識の通り、古いトークンを無効にして新トークンを発行しようと考えていました。

> この実装だと、なんらかの理由（例えばネットワークの不調）でレスポンスを取りこぼした際に、認証状態が維持されなくなります。再度認証すればよいのですが、そこまでのセキュリティが必要なのでしょうか?

なるほど。取りこぼしの想定をしていませんでした。
おっしゃる通り、何らかの通信エラーが発生したときに認証状態を保てなくなりますね。
私が頂いていた懸念点としては何となく都度、トークンを更新してあげることでより安全になると考え今回このような質問を投稿させて頂きました。
それと都度更新を考えた理由としては、JWTトークンの期限が切れるまでそのトークンを利用するとなると期限切れた時にログアウトになってしまうのがユーザー体験として良くないと思い、都度更新することで利用期限切れによるログアウトを防げると思い都度更新を前提に考えていました。
今回の質問から趣旨が外れてしまうのかもしれないのですが、フロントエンドはSPAサイトで作り、バックエンドをAPIで開発するとした時に認証トークン切れまでそのトークンを使い、切れたらログアウトにするというのはユーザー体験を考えたときによい体験には思えないので日頃からアクセスしているユーザーの場合、どういった実装をすることで利用期限切れによるログアウトを防げるかもし可能であればご教示いただけると嬉しいです。

[ockeghem]

> 認証トークン切れまでそのトークンを使い、切れたらログアウトにするというのはユーザー体験を考えたときによい体験には思えないので日頃からアクセスしているユーザーの場合、どういった実装をすることで利用期限切れによるログアウトを防げるかもし可能であればご教示いただけると嬉しいです

こちらはリフレッシュトークンというものを使うのが通常の実装となっています。「リフレッシュトークン」で検索すれば記事は数多く見つかると思います。

[nanase21]

ご教示頂きありがとうございました。
リフレッシュトークンの実装について試してからもう少しお聞きしたいことがあり遅くなりました。

Answer 2

ご指摘内容を考えると、都度更新しなくてもセキュリティはそれなりに担保されるという背景でご指摘を頂いたのでしょうか？

セキュリティを気にしての話なら、基本的には「有効期限はできるだけ短くする」「自動延長はしない」ということになります。なので 、そもそも延長は考えないで、上の質問へのコメントに書いたように、期限切れのユーザーがアクセスしてきたら、再度ログインしてもらってトークンを再発行するのが良いと思います。

客の要求とかの事情があってどうしてもということであれば、「更新した認証トークンをresponseのheaderに載せて返す」のが最初のログインでやっていることでしょうから同じで良いのではないかと思います。

サーバー側での判定と再発行、クライアント側での対応はかなり大変そうですが、そのあたりはできる目処がたっているのですか？

Comments

[nanase21]

ご教示頂きありがとうございます。

> サーバー側での判定と再発行、クライアント側での対応はかなり大変そうですが、そのあたりはできる目処がたっているのですか？

すいません。こちらについては、私の不勉強により大変さについて考慮できていませんでした。

それと、今回このような質問をさせて頂いた背景としては、基本的なトークン認証についての知識が無くどういった実装をすることで認証トークンAPIを安全に作れるかについて知りたく質問をさせて頂いたいのでとても勉強になりました。
私の中でまだ、理解し切れない部分はありますがご教示頂いたアドバイスを参考に勉強してみたいと思います。

[退会済みユーザー]

> こちらについては、私の不勉強により大変さについて考慮できていませんでした。

そこを考えないと・・・