better auth と keyclock どういう役割分担

Better Auth（アプリ側の認証ライブラリ）と Keycloak（IdP＝認証基盤）は、ざっくり言うと 「アプリに組み込む層」 と 「組織として共通化する認証サーバ層」 の役割分担です。競合というより“組み合わせる/どちらかを選ぶ”対象になります。

それぞれの役割

Better Auth（例：Next.js/Node に組み込む認証）

  • アプリにログイン機能を実装するためのライブラリ
  • セッション管理、Cookie、CSRF、コールバック処理、DB 連携（ユーザー作成/更新）など「アプリ実装の都合」を面倒見てくれる
  • “そのアプリの中で完結する認証”を作りやすい 例：メール＋パスワード、Magic Link、ソーシャルログイン（Google/GitHub）などをアプリ主導で実装

    • 向いているケース

  • 1プロダクト中心で、まずは早く認証を作りたい
  • 認証要件が比較的シンプル（社内SSOや厳格なポリシーが必須ではない）
  • 「ユーザーDB」「権限」をアプリが主に持つ設計にしたい

    • Keycloak（IdP / OAuth2・OIDC・SAML を提供する認証サーバ）

  • 認証・SSO・ユーザー管理を“中央集権”で提供するサーバ
  • OIDC/OAuth2/SAML の 発行元（トークンを出す側）
  • 組織ポリシー（MFA、パスワードルール、アカウントロック、条件付きアクセス、連携IdP、監査ログ等）をまとめて管理
  • 複数アプリを SSO でつなぐ、B2B（顧客企業ごとのRealm/テナント）的な構成も取りやすい

    • 向いているケース

  • 複数の社内/顧客向けアプリをSSOで統一したい
  • MFAや監査、細かいセキュリティ要件がある
  • 将来的にアプリが増える/別言語・別基盤にも同じ認証を使いたい

    • 一緒に使うなら：典型的な分担

    Keycloak = 認証（ログイン画面とトークン発行）

    Better Auth = アプリ側の受け口（セッション化、アプリ用ユーザー情報の同期、画面側の扱いやすさ）

    流れ（例）

  • ユーザーはアプリからKeycloakへリダイレクトしてログイン（OIDC Authorization Code + PKCE が一般的）
  • KeycloakがID/Access Tokenを発行
  • アプリ（Better Auth側）がそれを受け取り、自分のアプリのセッション（Cookie）に変換したり、必要ならユーザーをDBに作成/更新
  • API呼び出しは「アプリのセッション」または「KeycloakのAccess Token」で認可

    • ※ただし「Better AuthがKeycloakを“IdPとしてどこまで”サポートしているか」は、アダプタ実装の有無・バージョンで変わるので、実装方針としては「OIDCプロバイダとしてKeycloakを登録できるか（Discovery URL/Client設定）」がポイントになります。

    どっちを“主役”にするかの判断基準（超短縮）

  • SSO/組織ポリシー/複数アプリ前提 → Keycloak中心（アプリはOIDCクライアント）
  • 単一アプリでスピード優先、実装の自由度優先 → Better Auth中心（必要なら後でIdP移行）
  • 将来はSSOしたいが今は早く作りたい → まずBetter Authで作り、早めにKeycloak/OIDC移行を見越した設計（認可・ユーザIDの持ち方を固定しすぎない）

    • 必要なら、前提（B2Cか社内向けか / アプリ数 / MFA要件 / APIは同一ドメインか別か）を教えてくれれば、「Better Auth単体」「Keycloak単体」「併用」のおすすめ構成をもう一段具体化して整理できます。

    ← 戻る