現在、マイクロサービスアーキテクチャを構築しており、認証サーバーとクライアントから開始しています。また、トークンを使用してユーザーを認証する最善の流れを確認したかったのです。上記画像におけるマイクロサービスのJWTフローの修正
。ステップ3は私が混乱し始めたことです。 私はこの問題に対する2つの解決策を考えました。
すべてのapiがトークンを認証サーバーに渡し、内部に格納されているトークンがdbと一致し、それでも有効であるという承認を得るまで待機します。
2つは、JWTトークンに秘密の句を含めることで、トークンが有効であればAPIサービスで解析してチェックするだけです（秘密の句は、ハッカーがトークンを偽造しようとするとトークンを暗号化するために使用された秘密のコードなしでフレーズが無効になる可能性があるかどうかはわかりませんが、そうでなければ2が最良の行動コースになると思います）
署名鍵がわからない場合、ハッカーは有効なJWT tokenを作成できません。もし彼が何らかの形でその署名鍵を手に入れたら、彼があなたの "秘密の言い回し"も手に入れることができると仮定することは合理的です。
チェックについて：JWT tokensは、APIサービスが知っている必要がある署名キーを除き、必要なすべての情報が含まれているので、API serviceで確認できます。有効期限もここで確認できます。とにかく、ユーザーIDのようなトークンの内部に格納されている情報も必要です。スケーラビリティを向上させたい場合は、これを行う必要があります。
JWT tokenを第3のAuth serviceと照合する必要がある唯一の理由は、無効化されているかどうかです。このためには、無効なトークンのリストをすべてのAPI servicesに複製して復元力を高めることができますが、中央サービスが必要です。
本当にJWTトークンを検証するためにAuth-serverにリクエストを転送する必要はありません。 A JWTトークンは、請求書のようなものです、それが署名されたら、鍵を共有している誰でも検証できます。
には、すべてのAPIサービスの前にエッジサービスがあることをお勧めします。エッジサービスは、JWTトークンがAuthサービスによって署名された鍵を共有するか、署名を検証するための公開鍵を持っています。
署名が検証されると、エッジサービスはトークンから必要な情報を抽出し、要求ヘッダーに追加できます。ダウンストリームサービスは、必要に応じてこの情報を消費できます。
Httpsを使用すると、要求がネットワーク上の誰かによって傍受されないようにすることができます。場合は、誰かがJWTトークンを台無しにしようとすると、署名が一致しないことを検出することができます。パブリック/プライベートキーを使用してJWTトークンを作成/解析する方法の詳細については、JWT/KONG: Cannot create JWTs with a shared secretを参照してください。