JWTによるステートレス認証：更新トークンはステートレスではありません
現在のアーキテクチャでは、バックエンドがJWTを（モバイル）クライアントに発行します。 JWTを選択する主な理由は、ステートレス認証です。つまり、サーバーはセッション/データベースにデータを格納する必要がないため、オーバーヘッドとスケーラビリティの問題が少なくなります。
一般的な戦略は、ユーザーにログインし、短期間有効なJWT（約15分-私が読んだとおり）を、ユーザーがクライアントに保存する更新トークンと共に返すことです。更新トークンは期限切れになることはなく、取り消すことができます。目的は、長期間にわたってJWTを送信するのを避け、有効期限が切れたときにのみJWTを更新することです。攻撃者が短命のトークンを手に入れると、攻撃時間枠は短くなります。
問題は、私が考えると、この物語は穴があふれているように見えることです。はっきりさせてください。
- 15分の有効期限は、一部のユーザーが1日に10回、ネットワーク経由で更新トークンを送信する可能性があることを意味します。これは、一部のユーザーが通常の有効期間の短いアクセストークンを使用してリクエストを行うのと同じくらい高い頻度である場合があります。したがって、更新トークンの引数は疑わしいようです。
- SSLについて質問した場合、なぜ多くの企業が基本認証を使用するのかわかりません。リフレッシュトークンでJWTを使用するには、おそらくHTTPSを使用する必要があります。
- クライアントに新しいjwtを発行するためにセッション/データベースに更新トークンを保存する必要がある場合、JWTの利点は何ですか。この場合、更新トークンは、バックエンドに格納される一種のパスワードとして機能します（まったく同じではないことに気付きます）。これにより、認証フローが本質的にステートフルになり、JWTを完全に使用することの利点が失われるようです。また、15分の短い有効期限では、オーバーヘッドが大きく、30分間隔で電話を確認するたびに、更新されたアクセストークンを取得する必要があることを意味します。保存された更新トークンを確認するオーバーヘッドがあるだけでなく、更新トークンがブラックリストに登録されているかどうかを確認する必要があります。これは、別のパフォーマンスのオーバーヘッドを意味します。 （編集：最後のチェックは、取り消されたときにデータベースから更新トークンを削除するだけで削除できます）。
- 更新トークンには、複数のサーバーラウンドトリップが必要です。
- 401は、アクセストークンの有効期限が切れたときに返されます（リソースサーバー）。
- 認証サーバーで新しいアクセストークンをリクエストする必要があります
- リソースサーバーへの要求を再開する必要があります。
誰かが私にここで何が欠けているのか説明してくれますか？
ステートレスセッショントークンの主な批判の1つは、安全なログアウトがないことです。別のアクセス/更新トークンを使用すると、妥協が可能になります。 15分の遅延のある安全なログアウト機能を使用しながら、データベースアクセスの量を大幅に削減できます。
この設計では、セッションの乗っ取り、つまりトークンの悪意のあるキャプチャからの保護は何も行われません。 SSLを使用するだけで、最近ではユビキタスになっています。
注意して往復の量を減らすことができます。多くのクライアントHTTPライブラリではプロアクティブな認証を実行できるため、401を取得するための余分なラウンドトリップが回避されます。
それは特に賢明なデザインではないことに同意します。いずれにせよ、ほとんどのWebサイトはデータベースの負荷が高いため、各リクエストでトークンを確認してもオーバーヘッドはそれほど大きくありません。また、アクセス/更新トークンの基本概念は安全ですが、複雑さが増すことで実装に欠陥が生じることを心配しています。
この質問に対する他の答えがない限り、私自身の現在の解決策は、パフォーマンスに対するセキュリティリスクのトレードオフを評価する問題であるということです。
私の主な考慮事項は、「短期間」のjwtアクセストークンの時間枠を15分から1日に増やすことです。
これは、HTTPSが必要であり、リクエストが内部でのみ行われること、つまり、トークンがクロスドメインを移動しないことを前提としています。
つまり、パフォーマンスの観点から、トークンの更新は1日に1回だけ行われます。理論的には、SSLは私の場合十分なセキュリティを提供するはずです。攻撃ウィンドウの1日は、そもそも発生してはならない事態に対処するための単なるセキュリティ対策です。
更新トークンは基本的に認証プロセスをステートフルにしますが、リソースサーバーへのほとんどの要求（この場合は1日以上）は引き続きjwtを使用して発生するため、これは許容できる場合があります。