OAuth 2.0の

Question

シナリオ：

1. コントローラプロセスがトークン短命JWTのアクセスを取得し、リフレッシュトークンハンドルを使用して、クライアントの資格情報を付与します。
2. コントローラは、1つまたは複数の隔離されたワーカーノードを生成し、そのノードにアクセスおよび更新トークンを渡します。
3. 子ノードは、アクセストークンが期限切れになり、リフレッシュが発生する必要がある長期実行タスクを続行することがあります。
4. 有効期限が切れるバックグラウンドスレッドでは、エージェントがトークンをリフレッシュし、アクセストークンが再生成されます。短期間のアクセス・トークンとリフレッシュ・ライフサイクルの必要性は、一時的なJWTクレーム（ウイリスのような時間推移の主張）を再生成することです。
5. 子は親に対して応答を返すことがあります。親と子の両方は、他のメンバーを無効にすることなく、独立したセッション検証ライフサイクルを維持する必要があります。

前提条件： 各プロセスは、独立した状態のアトミック作業単位であると仮定します。アクセストークンはコントローラによって一度認証され、そのリフレッシュトークンと共にN + 1またはN * Nワーカーノードに渡されます。

任意のNプロセスは、リフレッシュトークンをそのアクセストークンにプロアクティブに再生成して、そのリフレッシュトークンに渡して、その存続期間を延長し、有効期限を防ぐことができます。

このプロセスは、HTTPS & SSLを介して信頼できる（プライベート）環境または信頼できない（パブリック）環境で実行される場合があります。

1つの認証サーバーと1つのAPIリソースサーバーがあります。

問題：エージェントはアクセストークンとリフレッシュトークンの両方の有効期間を検証して、セキュリティ攻撃ベクトルを公開したり、プール内の別のエージェントを無効にすることなく、子プロセスまたは親プロセスがそのセッションをリフレッシュできることをどのように確認しますか？

Answer 1

これに対して、相互TLSクライアント証明書認証が適している場合があります。それは、提供されたデジタル証明書を検証することにより、両当事者が他人の身元を保証されるように互いを認証することを伴う。技術的に言えば、それは、クライアントアプリケーションがサーバーに自身を認証し、そのサーバーが信頼できる認証局（CA）によって発行された公開鍵証明書/デジタル証明書を検証することによってクライアントに自身を認証することを意味します。