コンテンツにスキップ

認証／認可＠マイクロサービス

はじめに

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


01. 認証

認証サービス

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

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


01-02. SSOパターン (独立パターン)

SSOパターンとは

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

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

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

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

SSOパターンの仕組み

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

microservices_authentication_type_sso


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

▼ Kong Gateway

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

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

次回、Kong Gateway (APIゲートウェイ) がフロントエンドからのリクエストをKeycloakにフォワーディングし、JWTトークンの署名を検証する。

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

microservices_authentication_type_sso_gateway


01-03. セッションパターン (集中パターン)

セッションパターンとは

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

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

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

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

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


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

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

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

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

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

microservices_authentication_type_session


01-04. JWTパターン (分散パターン)

JWTパターンとは

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

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

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

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


JWTパターンの仕組み

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

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

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

クライアントのフロントエンドアプリケーション側に保管したJWTトークンの失効が難しいというデメリットがある。

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

microservices_authentication_type_jwt


01-05. 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


JWTプロキシーがある場合

▼ AWS JWT Authorizer

ここでは、認証サービス（図では認可サーバー）から手動でJWTトークンを発行し、クライアントに共有すると仮定する。

  1. クライアントのフロントエンドアプリケーションはAWS API GatewayにJWTトークンを含むリクエストを送信する。
  2. AWS API Gatewayは、AWS JWT Authorizerにリクエストを送信する。
  3. AWS JWT Authorizerは認証サービス（図では認可サーバー）のJWKSエンドポイントにリクエストを送信する。
  4. AWS JWT Authorizerは認証サービス（図では認可サーバー）から検証に使用する公開鍵を取得する。
  5. AWS JWT AuthorizerはJWTトークンの有効性を検証する。
  6. AWS API Gatewayは、バックエンドにリクエストを送信する。
  7. バックエンドは、AWS API Gatewayにレスポンスを返信する。
  8. AWS API Gatewayは、クライアントのフロントエンドアプリケーションにレスポンスを返信する。

aws_jwt-authorizer


02. 認可

集中パターン

▼ 集中パターンとは

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

microservices_authorization_centralized-authorization

▼ 認可プロバイダーへの委譲

認可サービスとして認可プロバイダーを配置する。

認可スコープを検証し、もしマイクロサービスの認可スコープが不十分であれば、リクエストを拒否する。

microservices_authorization_centralized-authorization_external-provider


分散パターン

▼ 分散パターンとは

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

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

microservices_authorization_decentralized-authorization


ハイブリッドパターン

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

microservices_authorization_hybrid-authorization