REST経由でWebクライアントアプリケーションに通信する複数のマイクロサービスを保護するためのベストプラクティスと効率的なソリューションを探しています。Springセキュリティを使用したRESTマイクロサービスの保護
現在のセットアップ：
これらmicroservicesは春のフレームワークで、Javaで作られたとドッカー容器に実行されます。
クライアントはAngular 2アプリケーションです。
"ゲートウェイ"として機能する新しいμServiceを作成し、私のWebクライアントと他のサービスとの間の唯一の通信ポイントになります。
私はにログインJWTを格納することができ：
は、私は、リモート認証APIからJWT暗号化されたトークンを取得し、私はおよそ考えていた
ソリューション（のは、それがロック呼びましょう）クッキーを作成し、ゲートウェイに送信します。
ゲートウェイは、関連するμServiceに送信された最後のペイロードに埋め込まれ、トークンを新規データベースに格納します。
マイクロサービスはクエリを取得し、リモート認証サービスでユーザーロールをチェックし、十分な場合は200の結果と結果を返します。
編集
私たちは、WebSocketをを使用して、このように私たちのμServicesハイブにRabbitMQのブローカーを持っている、とする必要があります。 REST APIを確保するのと同じ方法でWebSocketを保護するために、ゲートウェイでセキュリティを管理し、マイクロサービスレベルでセキュリティを管理する必要があるかどうかはわかりません。たくさんのメッセージが通過するので、おそらくミドルウェアを取り除くと、そのことが遅くなるはずです。
質問：
が、それは良い習慣ですか？おそらくもっとうまくいくだろうか？同じニーズを満たしていることの実例はありますか？あなたの株式のために多くのありがとう&思考。
私は同様のアプローチを採用しましたが、1つの領域が異なります。ユーザーJWTトークンは、ゲートウェイからサービスに渡されません。ゲートウェイ自体はクライアントトークンを取得し、それを使用して他のサービスに対して自身を認証します。私がこの設計を選んだのは、ユーザーのセキュリティがゲートウェイにローカライズされているからです。ゲートウェイは他のサービスによって完全に信頼されています。 – Leon
ええ、まったく同じことを自分に伝えていました。さらに、JWTトークンはとにかに格納する必要があるため、データの複製を避けるために、単一のエントリポイントに配置するのが適切です（必要に応じてゲートウェイに対して水平スケーラビリティを実行できます）。クッキー/セッション情報が盗まれるのを防ぐため、Webブラウザに格納されているDBバージョンと比較することができます。 迷惑な結果として、μServicesは互いの間で多くのHTTPトラフィックを生成し、これらを整理する「良い」方法ではないようです。 – Alex