コンテンツにスキップ

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

はじめに

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


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. セッションパターン (集中パターン)

セッションパターンとは

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

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

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

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

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


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

各マイクロサービスは、セッションIDに基づいてアカウントをする。

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

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

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

microservices_authentication_type_session


セッションIDをCookieヘッダーで運搬するパターン

マイクロサービスアーキテクチャの文脈では、セッションIDを使用した認証は次のような仕組みになっている。このパターンは、さまざまなフロントエンドアプリケーション (例：SST、CSR、SSRなど) で採用できる。

  1. 未認証のアカウントはフロントエンドアプリケーションにリクエストを送信する。
  2. IDプロバイダーはレスポンスのSet-CookieヘッダーでセッションIDを返信する。
  3. フロントエンドアプリケーションはIDプロバイダーのレスポンスヘッダーからセッションIDを取得する。セッションIDを再利用するため、ブラウザはCookieにセッションIDを保存する。
  4. フロントエンドアプリケーションは、セッションIDをCookieヘッダーで運搬する。
  5. マイクロサービスは、セッションIDに対応するセッションデータがストレージにあるか、またセッションIDが失効していないかを検証する。セッションIDはCookieヘッダーで運搬し、後続のマイクロサービスに伝播させる。

microservices_authentication_type_session_cookie-header


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. 認可

集中パターン

▼ 集中パターンとは

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

microservices_authorization_centralized-authorization

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

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

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

microservices_authorization_centralized-authorization_external-provider


分散パターン

▼ 分散パターンとは

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

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

microservices_authorization_decentralized-authorization


ハイブリッドパターン

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

microservices_authorization_hybrid-authorization