web-dev-qa-db-ja.com

マイクロサービスからマイクロサービスへの認証

相互に通信する必要のあるさまざまなマイクロサービスのバックエンドと、サービスの一部ではないシステムからのフィールドリクエストを利用する新しいアーキテクチャを計画しています。後半では、外部の顧客について話しているのではなく、ネットワーク内のシステムについて話しているだけですが、それはこのマイクロサービスアーキテクチャの一部ではありません。

相互に通信するこれらのサービスの認証/承認を処理する最良の方法は何ですか?私は通常、Oauth=をマイクロサービスのソリューションとして見ていますが、サービスを利用する外部の顧客について話す場合にそうなる傾向があります。マイクロサービスが互いに話す場合も同じですか?

10
Myelin

OAuth 2 クライアント資格情報付与 は、サービス間の通信用に設計されています。クライアント資格情報付与の認証には、通常、ログイン/パスワードではなく、共有シークレットを渡す必要があります。共有秘密は、クライアント資格情報付与のための「機密クライアント」のRFC要件を満たすために使用されます。

認証サーバーをまだお持ちでない場合は、少なくとも概念実証のために Keycloak をご覧になることをお勧めします。これはRedHatのオープンソース製品です。 OAuth 2(IDレイヤーを追加)の拡張であるOpen ID Connect(OIDC)を利用しています。詳細については、Keycloakの サービスアカウントに関するサーバー管理ドキュメント を参照してください。

3
HTLee

私は同様のケースに取り組んできました。 OAuth2を実装しました RFC-6749

認可マイクロサービスが欲しかったので、これは認証関連の操作のみを処理し、ネットワークの外部と内部で機能します。

このサービスのAPIは、OAuth2に必要なすべてを処理するのに十分汎用的です。 RFC-6749 のセクション「1.2。プロトコルフロー」のフローに従うことをお勧めします。これは、そのようなサービスの設計に役立つはずです。責任がサービスごとに固有である方法。これは、マイクロサービスを操作するときに本当に達成したいことです。

0
R Rodriguez