長時間実行される呼び出しのJWT有効期限をどのように処理しますか？
現在、複数のマイクロサービスのセキュリティ保護について議論しています。主な懸念事項は、提供されたJWTトークンが、呼び出しが終了する前に期限切れになることです。 （これは同期設計にあります）ここに3つの提案があります。
- クライアントアプリには、長い呼び出しの前に 'ensure（int minutes）'メソッドがあり、必要に応じてトークンプロバイダーを呼び出します。 JWTがセキュリティフィルターに達した場合は期限切れにします。
- クライアントアプリは、JWTと更新トークンの両方を送信します。 JWTの有効期限が切れた場合は、更新トークンを使用して新しいトークンを取得し、トークンプロバイダーを介して応答ヘッダーに配置します。
- 「ログイン」サービスを作成します。ログインは更新情報をキャッシュし、JWTを返します。古いJWTを送信して、トークンプロバイダー経由で更新されたJWTを取得します。
考え？注：私の投票は＃1です。残りは安全ではないように見えますが、便利です。
JWTトークンの期限切れが問題になると思う理由がわかりません。メッセージがシステムに到達した（リクエストが送信された）ときにのみ、有効期限を検証する必要があります。サービスの前にキューがある場合は、トークンを含むメッセージがキューに入る前に、トークンを確認/検証する必要があります。時間がかかるサービス操作がある場合は、処理の終了時ではなく、開始時に有効期限を確認してください。
マイクロサービスパターンによって作成される1つの重要な機能は、イベントのストリームに応答できることです。これは当然、再生のデータの一部が期限切れになることを意味します。
Expiryは、システム外のユーザーがシステムに対して「リプレイ」攻撃を使用できないようにするメカニズムとして意図されています。データがシステム内に収まったら、有効期限を確認する必要はもうありません。
クライアントアプリは、JWTと更新トークンの両方を送信します。 JWTの有効期限が切れた場合は、更新トークンを使用して新しいトークンを取得し、トークンプロバイダーを介して応答ヘッダーに配置します。
応答ではなく、リクエストヘッダーで処理されることを除いて、ほとんどが正しいです。
したがって、Web APIは有効なJWTを含むリクエストを1分で期限切れにして5分間実行し、サーバーが応答を発行し、jwtが期限切れであるために次のリクエストが401になり、次にトークンを更新する呼び出しが行われます。作成する必要があります（この場合、更新トークンの有効期限は5分より長くする必要があります）。