2016-07-22 12 views
2

セキュリティを適用するための複数のマイクロサービスアーキテクチャがあります。

セキュリティ設計のマイビュー: 、認証はLDAPで発生し、ユーザーが認証されたときにJSONウェブトークン(JWT)が「秘密鍵」を使用して生成されますと、トークンが役割を持っています有効期限などを指定します。マイクロサービスへの呼び出しごとに、このトークンは承認のためにヘッダーに渡されます。私の見解では、ユーザーを認証してJWTを生成する単一の認証サーバーしかありません。SpringCloud Microservices JSON Webトークン(JWT)セキュリティ

マイ・ダウト:今
は、microserviceは(ヘッダのJWTを含む)の呼び出しを受け取ることになりますそれは常にトークンが検証を取得するために認証サーバーを打つのだろうか?
「はい」の場合は、認証サーバーへの複数の呼び出しにつながり、悪い習慣につながることはありませんか?
がない場合、クライアントはトークンをどのように検証し、認証サーバーのスコープはどのようになりますか?

答えて

2

JWTは常に署名されているため、特定の中央認証インスタンスへの呼び出しを行わずに特定のトークンを検証できます。認証サーバーはトークンに署名する秘密を知っており、トークンを検証するすべてのサービスにもこれを確認する方法が必要です。

  • 対称::秘密の値はペイロードをハッシュする前に追加され

    は、署名に2つの異なるアプローチがあります。また、消費するサービスはこの秘密を知る必要があり、受信したペイロードに秘密を追加し、結果のハッシュを送信されたハッシュでチェックすることで検証できます。

  • 非対称:一部のPKI署名/検証を使用すると、認証サーバーだけがトークンに署名する秘密キーを持つことが可能です。消費しているすべてのサービスは、パブリック部分だけを検証する必要があります。

私は、キーが盗まれる可能性を減らすために、2番目の方法を好みます。消費するサービスの1つがハイジャックされると、攻撃者が有効なトークンを作成できるように秘密が失われることはありません。このようなアルゴリズムを使用すると、対称的な方法で使用される単純なハッシュよりも検証のために、より多くの時間/ CPUサイクルを要する可能性があります。

異なるメカニズムの例については、公式JWTのページをご覧ください。https://jwt.io/

+0

が、これはそれを最大限に答え、ありがとうございます。したがって、すべてのマイクロサービスに共通する公開鍵を持っている場合、公開鍵を配布する最良の方法は何ですか?マイクロサービスの場合は、DBまたは設定サーバーを経由しますか? –

+0

すでに実行中の設定サーバーがあり、PKIバージョンを使用している場合、この方法で公開鍵を配布する問題はありません。この通信は安全でなければならないことに注意してください。別のアプローチは、いくつかの集中キーレジストリからキーをフェッチすることです。名前をリストアップする特殊なプロパティー 'kid'があります。詳細は、jws付録を参照してください。https://tools.ietf.org/html/rfc7515#appendix-D –

関連する問題