私のJWT実装についての考え

Question

そのため、私はJWTトークン化についてできるだけ多くのことを学ぼうと努力してきましたが、auth0は事実上のJWT情報ハブのようです。

しかし、リフレッシュトークンについて読むほど、私はうんざりします。「無限に」リフレッシュ可能（または少なくとも非常に長い有効期限）の考えは、私には受け入れられません。

だからここに実装することに決めました。

システムのアーキテクチャ：1. API（純粋なAPIレイヤー、現時点では認証サーバー）-トークンを作成して検証します2.アプリレイヤー（リクエストを処理するフラスコ）。

ユーザーがアプリにアクセスしようとすると、ログインページに送られます。詳細を入力すると、APIの/ authorizeエンドポイントに送信されます。

これらの詳細が検証され、次の内容を含むクレームを使用してトークンが作成されます。

認証サーバーとAPIに関する限り、このトークンは30分で有効期限が切れます。

アプリレイヤーで、各リクエストはトークンをチェックし、有効期限が切れる前に5分未満かどうかを確認します。

見つかった場合は、独自のJWTを作成します（APIが知っているのと同じ秘密で署名されています）。元のJWT（期限切れ間近）をペイロードオブジェクトとして使用し、それをauth/refresh_token上のエンドポイントに送信します

次に、/ refresh_tokenエンドポイントはトークンを検証し、ペイロードから元のトークンを抽出し、それを検証し、それが有効なトークン（まだ期限切れになっていない）かどうかを検証します。次に、最初に作成された時間をチェックし、最大タイムアウト（アプリのお客様が設定）に到達していないことを確認します。これは、システムのハード制限である12時間です（ただし、お客様は合計セッションを短くすることもできます）。これらのチェックに問題がなければ、新しいトークンが作成され、アプリレイヤーに送信されます。

このように、私の考えは次のとおりです。

Authサーバーは、元々Authサーバーによって作成されたJWTを含む信頼されたJWTを受信する必要があるため、この更新要求を常に信頼できます。つまり、アプリレイヤー（またはシークレットを持つサーバー）によってのみ作成された可能性があります。
Authサーバーは更新トークンを無制限に配布しません。
秘密が危険にさらされている場合-とにかくことわざになり、それが危険にさらされていることに気づくまで、あなたができることはほとんどありません-もちろん、信頼できるソースからのJWTへのリクエストを確実にするIPチェッカーがありますが、それでも-攻撃者が何をしているか知っていれば、IPスプーフィングは難しくありません。
アプリレイヤーには、ユーザーセッションを強制終了することで更新の送信を停止する機能があるため、侵害されたJWTは最大30分間「危険」になります。

多くの人がセキュリティについて非常に精力的に取り組んでいますが、このアプローチは適切なチェックとバランスを提供すると思いますか？

そうでない場合は、アイデア、プロセスの改善などを聞きたいと思います。セキュリティは確かに私の強力なスーツではないので、すべての助けをいただければ幸いです！

乾杯。

Jonah Benton · Answer

それ自体が批判的であることを意図せず、フィードバックを提供するだけのいくつかの考え：

アプリに独自のJWTを作成させる理由はありません。クライアントが提供するJWTを渡すだけです。
これは意図したことではないかもしれませんが、失効をやむを得ず遅らせることはお勧めできません。特定のJWTの周囲で何らかの妥協が検出された場合、JWTを更新不可にするだけでなく、直ちに拒否する必要があります。
有効期限内に任意のウィンドウを選択して、特別な更新動作を行うのではなく、有効期限を短くするだけのメリットはありません。混乱を招き、人間工学はユーザーにとってもはや役に立ちません。関連するポリシーの決定は、アクティビティがセッションを自動的に延長するかどうか（残り5分だけでなく、すべての要求で適用されるかどうか）と、期限切れのトークンの受信時に何が起こるかです。
関連して、「残りが5時間未満で、12時間の制限まで更新する」機構は、有効期限があり、認証トークンの有効期限が切れたときにチェックされる更新トークンを持つことと同じです。次に、12時間の寿命が24または48の寿命または他の任意の数値と本当に大きく異なるかどうかを考えます。
マルチデバイスアクセス、複数のリフレッシュ+ JWT、または同じことを考えますか？単一のデバイスからの同時アクセス。トークンを特定のIPまたはユーザーエージェントにバインドするなど、トークンの使用率を制限する他の潜在的なメカニズムについて考えます。
複数のアプリが最終的にこのシステムに関与するかどうかを考えます。

お役に立てば幸いです。