コンテンツにスキップ

認証/認可@マイクロサービス領域

はじめに

本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。


01. 認証

認証サービス

各マイクロサービスごとに認証処理 (ユーザーの識別、ユーザーの有効性の検証) を持たせるのではなく、認証の責務を持つマイクロサービスを1個だけ配置する。

この認証サービスは、認証情報を永続化するためのDB、またはセッションを保管するためのストレージを持つ。


SSOパターン (独立パターン)

▼ SSOパターンとは

『独立パターン』ともいう。

認証サービスはトークンベースの認証情報を使用し、トークンをCookieヘッダーやAuthorizationヘッダーで運搬する。

この認証サービスは、認証情報を永続化するためのDBを持ち、有効期限が切れればアクセストークンを無効化する。

認証サービスが単一障害点になるというデメリットがある。

▼ SSOパターンの仕組み

各マイクロサービスは、SSOのIDプロバイダーに認証を委譲する。

microservices_authentication_type_sso

▼ APIゲートウェイがある場合

初回のSSO時、フロントエンドからIDプロバイダーに直接的に認可リクエストを送信する。

その後、CookieにJWTを保管する。

次回、APIゲートウェイがフロントエンドからのリクエストをKeycloakに転送し、JWT仕様トークンの署名を検証する。

結果に応じて、宛先マイクロサービスにルーティングするかどうかを決める。

microservices_authentication_type_sso_gateway


セッションパターン (集中パターン)

▼ セッションパターンとは

『集中パターン』ともいう。

サーバー側に、セッションデータを作成する認証サービス (例:自前、Keycloakなど) を1個だけ配置し、認証処理 (ユーザーの識別、ユーザーの有効性の検証) を実行する。

この認証サービスは、セッションベースの認証情報を使用し、セッションをCookieヘッダーで運搬する。

セッションデータを再利用するために、ブラウザのCookieやセッションストレージツール (例:Redis) に保存する。

(認証サービスだけでなく各マイクロサービスもセッションストレージツールに接続できるようにする必要があるらしいが、Keycloakではそんなことない)

▼ セッションパターンの仕組み

各マイクロサービスは、セッションデータに基づいてユーザーを認証する。

1個のセッション中の認証情報をマイクロサービス間で共有するために、セッションデータを保管できるストレージ (例:Infinispan、Redisなど) を1個だけ配置する。

セッションベースの認証情報は、コンテナの相性が悪く、各マイクロサービスがセッションデータを持つ必要がある。

そのため、SessionStorageが必要になるというデメリットがある。

microservices_authentication_type_session


JWTパターン (分散パターン)

▼ JWTパターンとは

『分散パターン』ともいう。

サーバー側に、JWTを作成する認証サービス (例:自前、Keycloakなど) を1個だけ配置し、認証処理 (ユーザーの識別、ユーザーの有効性の検証) を実行する。

認証サービスはトークンベースの認証情報を使用し、トークンをCookieヘッダーやAuthorizationヘッダーで運搬する。

トークンを再利用するために、ブラウザのCookie、SessionStorage、またはLocalStorageに保存する。

▼ JWTパターンの仕組み

各マイクロサービスは、JWTに基づいてユーザーを認証する。

1個のセッション中の認証情報をマイクロサービス間で共有するために、リクエスト/レスポンスのヘッダーにJWTを埋め込み、クライアント側にJWTを保管させる。

トークンベースの認証情報の場合に、コンテナの相性が良く、各マイクロサービスはJWTを持つ必要がない。

クライアント側に保管されたJWT仕様トークンの失効が難しいというデメリットがある。

その解決策として、Opaqueトークンパターン (ゲートウェイ集中パターン) がある。

microservices_authentication_type_jwt


JWT + APIゲートウェイパターン (ゲートウェイ集中パターン)

▼ JWT + APIゲートウェイパターンとは

『ゲートウェイ集中パターン』ともいう。

JWTパターンにAPIゲートウェイを組み合わせたパターンであり、JWTパターンでJWT仕様トークンの失効が難しいというデメリットを解決する。

サーバー側に、JWTを作成する認証サービス (例:自前、Keycloakなど) を1個だけ配置する。

APIゲートウェイは、認証を集中的に管理し、認証とアクセストークン署名検証を担う。

認証サービスはトークンベースの認証情報を使用し、API Gatewayを介して、非SSOで認証を実施する。

▼ JWT + APIゲートウェイパターンの仕組み

各マイクロサービスは、JWTとOpaqueトークンに基づいてユーザーを認証する。

1個のセッション中の認証情報をマイクロサービス間で共有するために、リクエスト/レスポンスのヘッダーにJWTを埋め込む。

クライアント側にはJWTとペアになるOpaqueトークンを保管する。

また、APIゲートウェイやロードバランサーで、OpaqueトークンとJWT仕様トークンの間の相互変換を通信のたびに実行する。

トークンベースの認証情報の場合に、コンテナの相性が良く、各マイクロサービスはOpaqueトークンを持つ必要がない。

microservices_authentication_type_opaque-token


02. 認可

集中パターン

▼ 集中パターンとは

認可スコープを定義する認可サービス (例:自前、OpenPolicyAgentなど) を1個だけ配置し、認可処理を実行する。

microservices_authorization_centralized-authorization


分散パターン

▼ 分散パターンとは

認可処理を各マイクロサービスに実装する。

認可処理はドメインと結びつきが強いので、マイクロサービス側に実装すると拡張性が高くなる。

microservices_authorization_decentralized-authorization


ハイブリッドパターン

▼ ハイブリッドパターンとは

microservices_authorization_hybrid-authorization