マイクロサービス認証戦略

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

ここでの私の考えは、各サービス（たとえば、認証、メッセージング、通知、プロファイルなど）で各ユーザーへの一意の参照（論理的には彼のuser_id）と、idログインした場合に現在のユーザーの固有の参照を取得することです。

私の研究から、2つの可能な戦略があることがわかります。

1.共有アーキテクチャ

この戦略では、認証アプリは他のサービスの1つです。しかし、各サービスは変換を行うことができる必要がありますsession_id=> user_idしたがって、非常にシンプルでなければなりません。それが私がRedisを考えた理由です、それがkey：valueを保存するでしょうsession_id:user_id。

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

この戦略では、認証アプリによってのみ処理されるため、セッションストレージはそれほど重要ではありません。その後、user_id他のサービスに転送できます。Rails + Devise（+ Redisまたはmem-cached、またはcookieストレージなど）について考えましたが、可能性はたくさんあります。重要なのは、Service 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/

短い答え：Oauth2.0の種類のトークンベースの認証を使用します。これは、ウェブアプリやモバイルアプリなど、あらゆるタイプのアプリケーションで使用できます。Webアプリケーションに関連する一連のステップは、次のようになります。

1. IDプロバイダーに対して認証する
2. アクセストークンをCookieに保持する
3. webappのページにアクセスする
4. サービスを呼び出す

以下の図は、必要になるコンポーネントを示しています。Web APIとデータAPIを分離するこのようなアーキテクチャは、優れたスケーラビリティ、復元力、安定性を提供します

OpenID Connectを使用してこれを実装するには、APIゲートウェイパターンを使用する必要があります。ユーザーはIDPによって認証され、承認サーバーからJWTトークンを取得します。APIゲートウェイシステムは、このトークンをRedisデータベースに保存し、ブラウザにCookieを設定できます。APIゲートウェイはCookieを使用してユーザーリクエストを検証し、トークンをマイクロサービスに送信します。

API Gatewayは、マイクロサービスアーキテクチャのパブリックJavaスクリプトクライアントアプリ、従来のウェブアプリ、ネイティブモバイルアプリ、サードパーティクライアントアプリなど、あらゆるタイプのクライアントアプリの単一のエントリポイントとして機能します。

詳細については、http：//proficientblog.com/microservices-security/をご覧ください。

認証と承認の目的でidenittyサーバー4を使用できます

ファイアウォールアーキテクチャを使用する必要があるため、セキュリティ、堅牢性、スケーラビリティ、および使いやすさをより詳細に制御できます。