認証/認可＠マイクロサービスアーキテクチャ

はじめに

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

• https://hiroki-it.github.io/tech-notebook/

01. 認証

認証サービス

各マイクロサービスごとに認証処理を持たせるのではなく、認証の責務を持つマイクロサービスを1個だけ配置する。

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

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

▼ SSOパターンとは

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

サーバー側に、認証サービスをIDプロバイダーとして、SSOを実行する。

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

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

アクセストークン (JWT仕様またはそうでない場合がある) を使用する。

• https://zenn.dev/maronn/articles/aboun-microservices-auth-in-app#sso-%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E7%AE%A1%E7%90%86
• https://iopscience.iop.org/article/10.1088/1742-6596/910/1/012060/pdf#page=6

▼ SSOパターンの仕組み

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

• https://please-sleep.cou929.nu/microservices-auth-design.html
• https://engineer.retty.me/entry/2019/12/21/171549

▼ API Gatewayがある場合

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

その後、クライアントのローカルマシンのCookieディレクトリにJWTを保管する。

次回、API Gatewayがフロントエンドからのリクエストを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

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

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

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

サーバー側に、セッションデータを作成する認証サービス (例：自前、Redisなど) を1個だけ配置し、認証処理を実行する。

この認証サービスは、セッションデータを保管するためのストレージを持つ。

• https://zenn.dev/maronn/articles/aboun-microservices-auth-in-app#%E5%88%86%E6%95%A3%E3%82%BB%E3%83%83%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E3%82%88%E3%82%8B%E7%AE%A1%E7%90%86
• https://iopscience.iop.org/article/10.1088/1742-6596/910/1/012060/pdf#page=6

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

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

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

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

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

• https://please-sleep.cou929.nu/microservices-auth-design.html
• https://engineer.retty.me/entry/2019/12/21/171549
• https://dev.to/honatas/a-different-approach-to-user-sessions-in-microservices-5bpi
• https://blog.stackademic.com/backend-for-frontend-authentication-pattern-in-go-5fe5ec7ced53

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

▼ JWTパターンとは

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

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

この認証サービスは、認証情報を永続化するためのDBを持つ。

SSOパターンと似ているが、こちらは非SSOでJWT仕様のトークンを使用する。

• https://iopscience.iop.org/article/10.1088/1742-6596/910/1/012060/pdf#page=7

▼ JWTパターンの仕組み

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

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

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

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

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

• https://please-sleep.cou929.nu/microservices-auth-design.html
• https://blog.stackademic.com/backend-for-frontend-authentication-pattern-in-go-5fe5ec7ced53
• https://engineer.retty.me/entry/2019/12/21/171549

Opaqueトークンパターン (ゲートウェイ集中パターン)

▼ Opaqueトークンパターンとは

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

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

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

API Gatewayは、認証を集中的に管理し、認証とアクセストークン検証を担う。

• 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

▼ Opaqueトークンパターンの仕組み

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

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

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

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

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

• https://please-sleep.cou929.nu/microservices-auth-design.html
• https://engineer.retty.me/entry/2019/12/21/171549

02. 認可

集中パターン

▼ 集中パターンとは

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

• https://zenn.dev/she_techblog/articles/6eff1f28d107be#decision%EF%BC%88%E8%AA%8D%E5%8F%AF%E3%81%AE%E5%88%A4%E6%96%AD%EF%BC%89%E3%81%AE%E5%AE%9F%E8%A3%85%E6%96%B9%E6%B3%95%EF%BC%88options-for-implementing-authorization-decisions%EF%BC%89

分散パターン

▼ 分散パターンとは

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

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

• https://zenn.dev/she_techblog/articles/6eff1f28d107be#decision%EF%BC%88%E8%AA%8D%E5%8F%AF%E3%81%AE%E5%88%A4%E6%96%AD%EF%BC%89%E3%81%AE%E5%AE%9F%E8%A3%85%E6%96%B9%E6%B3%95%EF%BC%88options-for-implementing-authorization-decisions%EF%BC%89

ハイブリッドパターン

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

• https://zenn.dev/she_techblog/articles/6eff1f28d107be#decision%EF%BC%88%E8%AA%8D%E5%8F%AF%E3%81%AE%E5%88%A4%E6%96%AD%EF%BC%89%E3%81%AE%E5%AE%9F%E8%A3%85%E6%96%B9%E6%B3%95%EF%BC%88options-for-implementing-authorization-decisions%EF%BC%89