マイクロサービス認証戦略 質問する

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

ここでの私のアイデアは、各サービス (認証、メッセージング、通知、プロファイルなど) に各ユーザーへの一意の参照 (当然ながらそのユーザーのuser_id) を持たせ、ログインしている場合は現在のユーザーの参照を取得できるようにすることですid。

私の調査によると、2 つの戦略が考えられます。

1. 共有アーキテクチャ

この戦略では、認証アプリは他のサービスの 1 つです。ただし、各サービスが変換を実行できなければならないsession_idためuser_id、非常にシンプルである必要があります。そのため、キー:値を保存する Redis を考えましたsession_id:user_id。

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

この戦略では、セッション ストレージは認証アプリによってのみ処理されるため、実際には重要ではありません。その後、user_id他のサービスに転送できます。私は Rails + Devise (+ Redis または mem-cached、または cookie ストレージなど) を考えましたが、可能性は無数にあります。唯一重要なことは、サービス X がユーザーを認証する必要がないことです。

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

• 安全
• 堅牢性
• スケーラビリティ
• 使いやすさ

あるいは、ここで言及していない別の解決策を提案していただけますか?

私は解決策 1 の方が好きですが、正しい方向に進んでいるという確信を得られるデフォルトの実装はあまり見つかりませんでした。