認証／認可＠マイクロサービス¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. 認証¶
認証マイクロサービス¶
各マイクロサービスごとに認証処理 (ユーザーの識別、ユーザーの有効性の検証) を持たせるのではなく、認証の責務を持つマイクロサービスを 1 個だけ配置する。
この認証マイクロサービスは、資格情報を永続化するための DB、またはセッションを保管するためのストレージを持つ。
HTTPサーバーの場合¶
認証では、ブラウザとの間で認可リクエストや認可レスポンスなどが発生する。
ブラウザは gRPC クライアントとして使えないため、認証マイクロサービスは HTTP サーバーにしたほうがいい。
gRPCサーバーの場合¶
前述のとおり、ブラウザは gRPC クライアントとして使えないため、認証マイクロサービスは HTTP サーバーにしたほうがいい。
認証マイクロサービスを gRPC サーバーとする場合、認証マイクロサービスの前方に HTTP サーバーで受信して gRPC クライアントとしてリクエストを送信するゲートウェイが必要になる。
01-02. SSOパターン (独立パターン)¶
SSOパターンとは¶
『独立パターン』ともいう。
認証マイクロサービスはトークンベース認証を使用し、アクセストークンを Cookie ヘッダーや Authorization ヘッダーで運搬する。
この認証マイクロサービスは、資格情報を永続化するための DB を持ち、有効期限が切れればアクセストークンを無効化する。
認証マイクロサービスが単一障害点になるというデメリットがある。
SSOパターンの仕組み¶
各マイクロサービスは、SSO の ID プロバイダーに認証を委譲する。
APIゲートウェイがある場合¶
▼ Kong Gateway¶
初回の SSO 時、フロントエンドから ID プロバイダーに直接的に認可リクエストを送信する。
その後、Cookie に JWT を保管する。
次回、Kong Gateway (API ゲートウェイ) がフロントエンドからのリクエストを Keycloak にフォワーディングし、JWT トークンの署名を検証する。
結果に応じて、宛先マイクロサービスにルーティングするかどうかを決める。
- https://www.jerney.io/secure-apis-kong-keycloak-1/
- https://blog.stackademic.com/backend-for-frontend-authentication-pattern-in-go-5fe5ec7ced53
- https://www.altkomsoftware.com/blog/keycloak-security-in-microservices/
- https://stackoverflow.com/a/53396041
- https://qiita.com/unhurried/items/998a386ccbc1ad4b8e61#rfc-8693-oauth-20-token-exchange
01-03. セッションパターン (集中パターン)¶
セッションパターンとは¶
『集中パターン』ともいう。
サーバー側に、セッション ID を作成する認証マイクロサービス (例：自前、Keycloak など) を 1 個だけ配置し、認証処理 (ユーザーの識別、ユーザーの有効性の検証) を実行する。
この認証マイクロサービスは、セッションベース認証を使用し、セッションを Cookie ヘッダーで運搬する。
セッション ID を再利用するために、ブラウザの Cookie やセッションストレージツール (例：Redis) に保存する。
(認証マイクロサービスだけでなく各マイクロサービスもセッションストレージツールへ接続できるようにする必要があるらしいが、Keycloak ではそんなことない)
セッションパターンの仕組み¶
各マイクロサービスは、セッション ID に基づいてアカウントをする。
1 個のセッション中の認証アーティファクトをマイクロサービス間で共有するために、セッション ID を保管できるストレージ (例：Infinispan、Redis など) を 1 個だけ配置する。
セッションベース認証は、コンテナの相性が悪く、各マイクロサービスがセッション ID を持つ必要がある。
そのため、SessionStorage が必要になるというデメリットがある。
セッションIDをCookieヘッダーで運搬するパターン¶
マイクロサービスアーキテクチャの文脈では、セッション ID を使用した認証は次のような仕組みになっている。このパターンは、さまざまなフロントエンドアプリケーション (例：SST、CSR、SSR など) で採用できる。
- 未認証のアカウントはフロントエンドアプリケーションにリクエストを送信する。
- ID プロバイダーはレスポンスの Set-Cookie ヘッダーでセッション ID を返信する。
- フロントエンドアプリケーションは ID プロバイダーのレスポンスヘッダーからセッション ID を取得する。セッション ID を再利用するため、ブラウザは Cookie にセッション ID を保存する。
- フロントエンドアプリケーションは、セッション ID を Cookie ヘッダーで運搬する。
- マイクロサービスは、セッション ID に対応するセッションデータがストレージにあるか、またセッション ID が失効していないかを検証する。セッション ID は Cookie ヘッダーで運搬し、後続のマイクロサービスに伝播させる。
01-04. JWTパターン (分散パターン)¶
JWTパターンとは¶
『分散パターン』ともいう。
サーバー側に、JWT を作成する認証マイクロサービス (例：自前、Keycloak など) を 1 個だけ配置し、認証処理 (ユーザーの識別、ユーザーの有効性の検証) を実行する。
認証マイクロサービスはトークンベース認証を使用し、アクセストークンを Cookie ヘッダーや Authorization ヘッダーで運搬する。
トークンを再利用するために、ブラウザの Cookie、SessionStorage、または LocalStorage に保存する。
JWTパターンの仕組み¶
各マイクロサービスは、JWT に基づいてアカウントを認証する。
1 個のセッション中の認証アーティファクトをマイクロサービス間で共有するために、リクエスト／レスポンスのヘッダーに JWT を埋め込み、クライアントのフロントエンドアプリケーション側に JWT を保管させる。
トークンベース認証の場合に、コンテナの相性がよく、各マイクロサービスは JWT を持つ必要がない。
クライアントのフロントエンドアプリケーション側に保管した JWT トークンの失効が難しいというデメリットがある。
その解決策として、Opaque トークンパターン (ゲートウェイ集中パターン) がある。
01-05. JWTとAPIゲートウェイの組み合わせパターン (ゲートウェイ集中パターン)¶
JWTとAPIゲートウェイの組み合わせパターンとは¶
『ゲートウェイ集中パターン』ともいう。
JWT パターンに API ゲートウェイを組み合わせたパターンであり、JWT パターンで JWT トークンの失効が難しいというデメリットを解決する。
サーバー側に、JWT を作成する認証マイクロサービス (例：自前、Keycloak など) を 1 個だけ配置する。
API ゲートウェイは、認証を集中的に管理し、認証とアクセストークン署名検証を担う。
認証マイクロサービスはトークンベース認証を使用し、API Gateway を介して、非 SSO で認証を実施する。
- https://zenn.dev/maronn/articles/aboun-microservices-auth-in-app#jwt%2Bapi-gateway-%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E7%AE%A1%E7%90%86
- https://iopscience.iop.org/article/10.1088/1742-6596/910/1/012060/pdf#page=8
- https://engineer.retty.me/entry/2019/12/21/171549
- https://please-sleep.cou929.nu/microservices-auth-design.html
JWTとAPIゲートウェイの組み合わせパターンの仕組み¶
各マイクロサービスは、JWT と Opaque トークンに基づいてアカウントを認証する。
1 個のセッション中の認証アーティファクトをマイクロサービス間で共有するために、リクエスト／レスポンスのヘッダーに JWT を埋め込む。
クライアントのフロントエンドアプリケーション側には JWT とペアになる Opaque トークンを保管する。
また、API ゲートウェイやロードバランサーで、Opaque トークンと JWT トークンの間の相互変換を通信のたびに実行する。
トークンベース認証の場合に、コンテナの相性がよく、各マイクロサービスは Opaque トークンを持つ必要がない。
- https://zenn.dev/maronn/articles/aboun-microservices-auth-in-app#jwt%2Bapi-gateway-%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E7%AE%A1%E7%90%86
- https://iopscience.iop.org/article/10.1088/1742-6596/910/1/012060/pdf#page=8
- https://engineer.retty.me/entry/2019/12/21/171549
- https://please-sleep.cou929.nu/microservices-auth-design.html
JWTプロキシーがある場合¶
▼ AWS JWT Authorizer¶
ここでは、認証マイクロサービス (図では認可サーバー) から手動で JWT トークンを発行し、クライアントに共有すると仮定する。
- クライアントのフロントエンドアプリケーションは Amazon API Gateway に JWT トークンを含むリクエストを送信する。
- Amazon API Gateway は、AWS JWT Authorizer にリクエストを送信する。
- AWS JWT Authorizer は認証マイクロサービス (図では認可サーバー) の JWKS エンドポイントにリクエストを送信する。
- AWS JWT Authorizer は認証マイクロサービス (図では認可サーバー) から検証に使用する公開鍵を取得する。
- AWS JWT Authorizer は JWT トークンの署名を検証する。
- Amazon API Gateway は、バックエンドにリクエストを送信する。
- バックエンドは、Amazon API Gateway にレスポンスを返信する。
- Amazon API Gateway は、クライアントのフロントエンドアプリケーションにレスポンスを返信する。
- https://qiita.com/KWS_0901/items/9b37712ed4bff75e1d4f
- https://auth0.com/blog/securing-aws-http-apis-with-jwt-authorizers/#Test-It-Out-
- https://dev.classmethod.jp/articles/amazon-api-gateway-http-api-authz-auth0/#%25E7%25A2%25BA%25E8%25AA%258D%25E3%2581%2597%25E3%2581%25A6%25E3%2581%25BF%25E3%2582%258B
02. 認可¶
集中パターン¶
▼ 集中パターンとは¶
認可スコープを定義する認可マイクロサービス (例：自前、Open Policy Agent など) を 1 個だけ配置し、認可処理を実行する。
▼ 認可プロバイダーへの委譲¶
認可マイクロサービスとして認可プロバイダーを配置する。
認可スコープを検証し、もしマイクロサービスの認可スコープが不十分であれば、リクエストを拒否する。
分散パターン¶
▼ 分散パターンとは¶
認可処理を各マイクロサービスに実装する。
認可処理はドメインと結びつきが強いので、マイクロサービス側に実装すると拡張性が高くなる。
ハイブリッドパターン¶
▼ ハイブリッドパターンとは¶
