認証/認可＠マイクロサービスアーキテクチャ¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. 認証¶
認証サービス¶
各マイクロサービスごとに認証処理を持たせるのではなく、認証の責務を持つマイクロサービスを1個だけ配置する。
SSOパターン¶
▼ SSOパターンとは¶
サーバー側に、IDプロバイダーを認証サービスとして、SSOを実行する。
認証サービスが単一障害点になるというデメリットがある。
▼ SSOパターンの仕組み¶
各マイクロサービスは、SSOのIDプロバイダーに認証を委譲する。
中央集権パターン¶
▼ 中央集権パターンとは¶
サーバー側に、セッションデータを作成する認証サービス (例：自前、Keycloak、など) を1個だけ配置し、認証処理を実行する。
▼ 中央集権パターンの仕組み¶
各マイクロサービスは、セッションデータに基づいてユーザーを認証する。
1個のセッション中の認証情報をマイクロサービス間で共有するために、セッションデータを保存できるストレージを1個だけ配置する。
耐障害性のあるセッションストレージが必要になるというデメリットがある。
JWTパターン¶
▼ JWTパターンとは¶
サーバー側に、JWTを作成する認証サービス (例：自前、Keycloak、など) を1個だけ配置し、認証処理を実行する。
▼ JWTパターンの仕組み¶
各マイクロサービスは、JWTに基づいてユーザーを認証する。
1個のセッション中の認証情報をマイクロサービス間で共有するために、リクエスト/レスポンスのヘッダーにJWTを埋め込み、クライアント側にJWTを保存させる。
クライアント側に保存されたJWTの失効が難しいというデメリットがある。
Opaqueトークンパターン¶
▼ Opaqueトークンパターンとは¶
サーバー側に、JWTを作成する認証サービス (例：自前、Keycloak、など) を1個だけ配置し、一方でクライアント側ではOpaqueトークンを保存し、認証処理を実行する。
▼ Opaqueトークンパターンの仕組み¶
各マイクロサービスは、JWTとOpaqueトークンに基づいてユーザーを認証する。
1個のセッション中の認証情報をマイクロサービス間で共有するために、リクエスト/レスポンスのヘッダーにJWTを埋め込む。
クライアント側にはJWTと対になるOpaqueトークンを保存する。
また、API Gatewayやロードバランサーで、OpaqueトークンとJWTの間の相互変換を通信のたびに実行する。
02. 認可¶
SSOパターン¶
▼ SSOパターンとは¶
サーバー側に、認可スコープを定義する認可サービス (例：自前、OpenPolicyAgent、など) を1個だけ配置し、認可処理を実行する。
JWTパターン¶
▼ JWTパターンとは¶
サーバー側に、認可サービス (例：自前、Keycloak、など) を1個だけ配置し、認可処理を実行する。
▼ サイドカーサービスメッシュ¶
サイドカーサービスメッシュを使用し、JWTパターンを実装する。
サイドカーは認可サービスにリクエストを送信し、認可サービスは認可スコープに応じてboolean型値を返却する。
