🔑

Keycloakによる認証BFF構築

に公開
Docker
FastAPI
認証
Keycloak
BFF
tech

はじめに

次のような方を対象にしています。

  • これから認証機能の実装をはじめる方
  • 認証機能のアーキテクチャに興味がある方

この記事で扱わないこと

  • 技術用語の詳しい解説

実現したいこと

この記事では、下記の技術スタックを用います。

  • Vue.js
  • FastAPI
  • Keycloak
  • Docker Compose

フロントエンドではkeycloak-jsライブラリは使用しません。keycloak-jsでは、アクセストークンをブラウザのメモリに保存するため、XSS攻撃に対する脆弱性があるためです。
代わりに、バックエンドにトークンを保存し、ブラウザ上ではトークンへのアドレスをCookie上に持たせる形で認証機能を実装します。

BFFアーキテクチャでの認証機能として最低限動作するところまで実装していきます。
少し長くなるかもしれませんが、最後までお付き合いください。

完成形の構成図

SPAにおけるKeycloakの使われ方と課題

  • SPAでは、keycloakのクライアントライブラリとしてkeycloak-jsが用いられることが多いです。keycloak-jsでは、keycloakが発行したトークンをブラウザのメモリまたはLocalStorageに保存します(デフォルトではメモリに保存)。
  • ブラウザがトークンを保持している場合、XSS攻撃によりトークンを奪われる可能性が生まれてしまいます。
  • この構成は実装が簡単なため、小規模なプロダクトでは採用されることが多いですが、今日求められるセキュリティレベルを満たさないという問題があります。

認証BFFとは

  • バックエンドがOIDCクライアントとしてKeycloakと通信してトークンを取得・保存します。
  • SPAはKeycloakと一切の通信を行いません。
  • バックエンドのセッションストアにトークンを保存し、ブラウザのcookieにsession_idを保存します。
  • バックエンドのAPIへのアクセス時に、cookieを付与してリクエストを行います。
  • バックエンドでsession_storeからsession_idをキーとしてトークンを取り出し、tokenを検証して認証認可を行います。
  • こうすることで、SPAがトークンを保持せずに認証機能を実現することができます。

詳しくは下記の記事を参照してください。
参考: # BFF (Backend for Frontend) パターン

記事一覧

記事の全体像は下記の構成を考えています。

  1. 実行環境の構築(docker composeの作成)
  2. login関数の実装(認可コードの取得)
  3. callback関数の実装(トークンの取得)
  4. トークンの検証
  5. フロントエンドからのAPI呼び出し
  6. API認可の実装
  7. ログアウトの実装
  8. token refresh処理の実装

Discussion