[解決済み] マイクロサービス認証戦略

質問

マイクロサービスアーキテクチャのための適切な/安全な認証戦略を選択するのに苦労しています。このトピックに関して私が見つけた唯一のSOポストはこれです。 マイクロサービスアーキテクチャにおけるシングルサインオン

私のアイデアは、各サービス（認証、メッセージング、通知、プロファイルなど）において、各ユーザーへの一意の参照を持つことです（非常に論理的に、彼の user_id を取得し、現在のユーザーの id ログインしている場合

調べてみると、2つの作戦が考えられるようですね。

1. 共有アーキテクチャ

この戦略では、認証アプリは他のサービスの中の1つです。しかし、各サービスは変換を行うことができなければなりません。 session_id => user_id ということで、非常にシンプルでなければなりません。そこで、Redisを思いついたのですが、これはキーと値を保存するものです。 session_id:user_id .

2. ファイアウォールのアーキテクチャ

この戦略では、セッションストレージは、認証アプリによってのみ処理されるため、実際には重要ではありません。次に user_id は、他のサービスに転送することができます。Rails + Devise (+ Redis or mem-cached, or cookie storage, etc.)を思いついたが、可能性は山ほどある。重要なのは、サービスXがユーザーを認証する必要がないことだけです。

この2つのソリューションは、どのように比較されますか。

• セキュリティ
• 堅牢性
• スケーラビリティ
• 使いやすさ

あるいは、ここに書いていない別の解決策を提案されるかもしれませんね？

私は1のソリューションの方が好きですが、正しい方向に進んでいるという事実を保証してくれるようなデフォルトの実装はあまり見つかっていません。

どのように解決するのですか？

私が理解したところでは、OAuth 2 プロトコルを使用することで解決するのが良い方法だと思います。 (でもう少し詳しく見ることができます。 http://oauth.net/2/ )

ユーザーがアプリケーションにログインすると、トークンを取得し、このトークンを使って他のサービスに送信し、リクエストの中でユーザーを識別することができるようになります。

連鎖型マイクロサービス設計例

リソース

• http://presos.dsyer.com/decks/microservice-security.html
• https://github.com/intridea/oauth2
• https://spring.io/guides/tutorials/spring-security-and-angular-js/