コンテンツにスキップ

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

はじめに

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


01. 認証

認証マイクロサービス

ユーザーの識別と認証アーティファクトの発行は、認証の責務を持つマイクロサービスに集約する。発行された認証アーティファクトの有効性は、フロントエンドアプリケーションや各マイクロサービスで検証する。

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


HTTP サーバーの場合

認証では、ブラウザとの間で認可リクエストや認可レスポンスなどが発生する。

ブラウザは gRPC クライアントとして使えないため、認証マイクロサービスは HTTP サーバーにしたほうがいい。


gRPC サーバーの場合

前述のとおり、ブラウザは gRPC クライアントとして使えないため、認証マイクロサービスは HTTP サーバーにしたほうがいい。

認証マイクロサービスを gRPC サーバーとする場合、認証マイクロサービスの前方に HTTP サーバーで受信して gRPC クライアントとしてリクエストを送信するゲートウェイが必要になる。


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 を使用した認証は次のような仕組みになっている。このパターンは、さまざまなフロントエンドアプリケーション (例：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. クライアントのフロントエンドアプリケーションは Amazon API Gateway に JWT トークンを含むリクエストを送信する。
  2. Amazon API Gateway は、AWS JWT Authorizer にリクエストを送信する。
  3. AWS JWT Authorizer は認証マイクロサービス (図では認可サーバー) の JWKS エンドポイントにリクエストを送信する。
  4. AWS JWT Authorizer は認証マイクロサービス (図では認可サーバー) から検証に使用する公開鍵を取得する。
  5. AWS JWT Authorizer は JWT トークンの署名を検証する。
  6. Amazon API Gateway は、バックエンドにリクエストを送信する。
  7. バックエンドは、Amazon API Gateway にレスポンスを返信する。
  8. Amazon API Gateway は、クライアントのフロントエンドアプリケーションにレスポンスを返信する。

aws_jwt-authorizer


02. 認可

集中パターン

▼ 集中パターンとは

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

microservices_authorization_centralized-authorization

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

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

認可プロバイダーは、アカウント属性やワークロード ID の認可スコープに基づいて操作の許否を決定し、その結果をマイクロサービスに返信する。マイクロサービスは結果に応じてリクエストを許可または拒否する。

microservices_authorization_centralized-authorization_external-provider


分散パターン

▼ 分散パターンとは

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

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

microservices_authorization_decentralized-authorization


ハイブリッドパターン

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

microservices_authorization_hybrid-authorization