Keycloakとは｜Auth0・Oktaとの違いと導入判断

Keycloakとは｜OSSの認証・認可基盤（IAM）

Keycloakは、アプリケーションの外側に置く認証・認可の専用サーバーです。ログイン画面、パスワード管理、多要素認証、外部IDとの連携といった処理をKeycloakに寄せ、アプリ側は「認証済みのユーザー情報を受け取るだけ」の状態にします。

自前でログイン機能を実装すると、パスワードのハッシュ化、リセットフロー、セッション管理、ソーシャルログイン連携などを延々と作り込むことになります。この一式を標準プロトコルに沿った形で肩代わりするのがKeycloakの役割です。

開発はRed Hatが主導してきました。2023年4月にCNCF（Cloud Native Computing Foundation）のIncubatingプロジェクトとして受け入れられ、執筆時点でもIncubatingの段階にあります。ライセンスはApache License 2.0です。最新の状況はCNCFのプロジェクトページで確認できます。

何を肩代わりしてくれるのか

Keycloakが標準で提供する主な機能は次のとおりです。

ログイン画面のデザイン変更や、認証フローへの独自ステップ追加も可能です。ただし、この「作り込める」という性質が後述する運用負荷にもつながります。

レルム・クライアント・ロールという3つの単位

Keycloakの設定を理解するうえで避けて通れないのが、レルム（Realm）とクライアント（Client）という概念です。

レルムは、ユーザー・クライアント・ロールをまとめて管理する独立した領域です。テナントやプロジェクトの単位と考えるとイメージしやすいでしょう。レルムを分ければ、参照するユーザーDBも、認証ポリシーも、ログイン画面も別々にできます。社内向けと顧客向けでレルムを分ける構成はよく見られます。

クライアントは、Keycloakに認証を委ねるアプリケーション1つ1つを指します。Webアプリ、モバイルアプリ、バックエンドAPIをそれぞれクライアントとして登録し、単位ごとにリダイレクトURIやトークンの有効期限を設定します。

ロールは権限の単位です。レルム全体に効くレルムロールと、特定クライアントの中だけで効くクライアントロールの2階層があります。

最初の設計でつまずきやすいのがレルムの切り方です。分けすぎると設定とユーザーが分断されて横断的な管理ができなくなり、分けなさすぎると権限設計が複雑化します。

対応プロトコルとトークンの扱い

KeycloakはOpenID Connect、OAuth 2.0、SAML 2.0に対応しています。新規のWebアプリやモバイルアプリではOpenID Connectを選ぶケースが中心で、既存の業務システムや外部SaaSとの連携でSAML 2.0が要求される、という使い分けになります。

発行されるIDトークンは通常JWTで、アクセストークンもJWTとして扱う構成が一般的です。トークンの中身や検証の考え方を押さえておかないと、有効期限の設計やAPI側の検証実装で手戻りが出ます。この前提知識は「OAuth 2.0とは｜認可の仕組み・4つのグラントとPKCEを解説」と「JWTとは｜仕組み・セッション認証との違い・実装の注意点」で整理しています。Keycloakの設定画面に出てくる用語の大半は、この2つのプロトコル仕様に由来します。

なお、サーバー本体はバージョン17以降でQuarkusベースに移行しました。起動時間とメモリ消費が以前より抑えられており、コンテナ前提の運用がしやすくなっています。Quarkus自体の特徴は「Quarkusとは｜クラウドネイティブJavaの特徴・Spring Bootとの違い」を参照してください。

ミニFAQ：Keycloakの基本

Q. Keycloakを入れれば、アプリ側の認証コードはゼロになりますか。

いいえ。ログイン画面とユーザー管理はKeycloakに寄せられますが、アプリ側にはトークンを受け取って検証し、セッションに結びつける実装が残ります。多くの言語・フレームワークでは、OpenID Connect／OAuth 2.0に対応した既存ライブラリやミドルウェアをそのまま使えるため、ゼロから書く量は大きく減ります。

Q. レルムは最初にいくつ作るべきですか。

用途が明確に分かれていないなら、まず1つで始めるほうが扱いやすくなります。後からレルムを分割するより、1レルム内でクライアントとロールを整理するほうが手戻りが小さく済むためです。

Keycloakの開発体制とライセンス｜コミュニティ版とRHBK

Keycloakを検討するとき、「Keycloak」という1つの製品があると考えると判断を誤ります。実際には、無償のコミュニティ版と、Red Hatが商用サポートを付けて提供するRed Hat build of Keycloak（RHBK）の2つが存在します。

コミュニティ版とRed Hat build of Keycloakの違い

ここが導入判断で最も見落とされる部分です。コミュニティ版は固定のEOL日付を公表する形式ではなく、実質的に最新版系が手当ての対象になります。セキュリティ修正を受け取り続けるには、リリースに追従してアップグレードする前提で考えておくのが安全です。

一方のRHBKは、Red Hat Single Sign-On（RH-SSO）の後継として2023年11月に一般提供が開始されました。RH-SSOは7.6が最終版で、既存ユーザーには移行が案内されています。RHBKにはコミュニティ版より長いサポートライフサイクルが設定されており、メジャーバージョン単位の対象期間とマイナーリリースのメンテナンス期間が公表されています。年数はポリシー改定で変わることがあるため、契約前にRed Hat build of Keycloakの製品ページで最新の条件を確認してください。

「無料」が指す範囲を正確にとらえる

Keycloakが無料なのは、ライセンス費と利用者数に対する課金です。ここは明確で、ユーザーが100人でも100万人でも、Keycloak自体の料金は変わりません。

無料ではないものは次のとおりです。

• サーバーのホスティング費用（複数ノード構成なら台数分）

• 外部データベースの費用（本番では必須）

• アップグレード対応の工数

• 障害対応と監視の体制

• 脆弱性情報の追跡と適用判断

最新安定版は数か月単位で更新されます。特定のバージョン番号を前提に検討を進めず、導入時にはKeycloak公式のダウンロードページでその時点の最新安定版を確認してください。

KeycloakとAuth0・Okta・Cognito・Entra IDの違い

結論から言えば、違いは機能の多寡ではなく責任の置き場所です。IDaaSは可用性・パッチ適用・スケーリングをベンダーが引き受け、Keycloakはそれを自社が引き受けます。機能面は、主要な認証プロトコルとMFAに関してはいずれも一通り揃っています。

提供形態とコスト構造の比較

Okta と Microsoft Entra ID は、どちらかといえば従業員向けのID管理（Workforce Identity）が主戦場です。顧客向けのログイン機能を作る用途では、Auth0（Oktaが買収）やAmazon Cognitoが比較対象に上がりやすくなります。自社サービスの会員登録・ログインを作るのか、社内の業務システムを統合するのかで、そもそも並べる製品が変わる点に注意してください。

Auth0との違いを実装目線で見る

Auth0は最短ルートを提供します。アカウントを作り、アプリケーションを登録し、SDKを入れれば、その日のうちにログインが動きます。インフラの準備は不要です。

Keycloakは、まずサーバーを立てるところから始まります。Dockerで開発用に起動するだけなら数分で済みますが、本番用となると、データベース、TLS終端、複数ノード構成、バックアップ、監視をひととおり用意することになります。

一方で、Auth0にできないこともあります。データベースを自社の管理下に置く、認証ログを自社のネットワーク内で完結させる、ログイン画面の挙動を細部まで作り変える、といった要件です。金融・公共・医療のようにデータの所在に制約がかかる領域で、Keycloakの採用例が見られるのはこのためです。

もうひとつ実務上の違いがあります。Auth0はベンダー側の仕様変更や料金改定の影響を受けます。Keycloakは自社がアップグレードの判断権を持ちます。これは裏返すと、判断しなければ古いまま放置されるということでもあります。

マルチテナント設計の考え方

B2B SaaSのようにテナントごとに認証を分けたい場合、Keycloakには2つのアプローチがあります。

従来からある方法が、テナントごとにレルムを分ける構成です。分離は強固ですが、テナント数が増えるとレルムの管理が重くなります。

もうひとつがOrganizations機能です。Keycloak 25でプレビューとして導入され、26系で正式機能になりました。1つのレルムの中に組織という単位を作り、組織ごとにメンバー、連携先IdP、招待フローを持たせられます。テナント数が多いB2B用途では、レルム分割より扱いやすいケースがあります。採用を検討する際は、Keycloak公式サイトの該当バージョンのドキュメントで機能範囲を確認してください。

ミニFAQ：製品比較

Q. Auth0からKeycloakへ移行する場合、パスワードはそのまま移せますか。

そのままエクスポートできないのが通常です。ハッシュ形式の互換性と、移行元サービスがハッシュの書き出しに応じるかどうかに依存します。実務では、移行期間中は旧IdPに認証を委譲し、ログインしたユーザーから順次Keycloakにパスワードを作り直す段階移行を取るケースがあります。

Q. 機能比較表で差がつかないなら、何を基準に決めればいいですか。

運用の引き受け先です。3年後に認証基盤を見られる人が自社にいるかどうかで決まります。この判断軸は次章で具体化します。

コストはどこで逆転するか

Keycloakのライセンス費はゼロですが、総コストがIDaaSを下回るとは限りません。逆転が起きる条件を整理します。

利用者数による費用カーブの違い

Auth0の料金体系を例に取ります。無料プランは月間アクティブユーザー25,000までが対象です。有料プランのB2C Essentialsは月額35ドルから（500 MAU込み、超過分は1 MAUあたり0.07ドル）、B2C Professionalは月額240ドルからという設定になっています。いずれもAuth0公式の料金ページに掲載されていた2026年8月時点の情報です。プラン構成・価格・無料枠はいずれも改定されるため、実際の見積もりでは必ず公式の料金ページで最新の条件を確認してください。

この構造から読み取れる傾向は次のとおりです。

• 利用者が少ないうちは、IDaaSの無料枠や低価格プランのほうが安い

• 利用者が増えるほどIDaaSの費用は上がり、Keycloakの費用はインフラ費として横ばいに近づく

• どこで逆転するかは、必要なプランのグレードとインフラ構成に左右されるため、一律の分岐点は示せない

重要なのは、比較対象を「ライセンス費ゼロ」対「月額料金」にしないことです。Keycloak側には人件費が乗ります。

見落とされがちな運用工数

Keycloakの実質コストの大半は、次の項目に消えていきます。

1. 初期構築：データベース設計、クラスタ構成、TLS設定、バックアップ設計

2. アップグレード対応：コミュニティ版は年4回程度のマイナーリリースがあり、追従判断と検証が定期的に発生する

3. 障害対応：認証基盤が落ちると、連携する全アプリがログインできなくなる

4. 脆弱性対応：公開された脆弱性情報を追い、影響範囲を判断して適用する

5. 要件追加への対応：MFAの方式変更、新しい外部IdPの追加、監査ログ要件

このうち2と4は、稼働後にずっと続きます。少人数のチームで「作った人が異動したあと誰も触れない」状態になると、認証基盤が古いバージョンのまま固定されます。これはセキュリティ上の負債としてかなり重いものになります。

導入判断チェックリスト｜Keycloakを選ぶ条件・避ける条件

ここまでの比較を、判断できる形に落とし込みます。

Keycloakが向くケース

以下のいずれかに強く当てはまるなら、Keycloakを検討する価値があります。

• データの所在に制約がある：認証情報を自社管理のインフラに置く要件が、契約や社内規程で定められている

• 利用者数が多く、今後も増える：MAU課金だと費用が読みにくい、または上限が見えない

• 認証フローに独自要件がある：標準的なログイン以外の追加ステップや、既存システム固有の認証方式を組み込む必要がある

• 既存のLDAP／Active Directoryを活かしたい：ユーザーフェデレーションで既存のディレクトリを参照する構成にしたい

• 運用を担える体制がある：インフラとアプリの両方を見られるエンジニアが、継続的に確保できる

IDaaSが向くケース

逆に、次の状況ではAuth0・Cognito・Entra IDのようなマネージドサービスのほうが合理的です。

• 立ち上げ速度が最優先で、認証に工数をかけたくない

• 開発チームが小規模で、インフラ運用の専任者がいない

• 利用者数が当面は少なく、無料枠や低価格プランに収まる

• 認証要件が標準的で、作り込みの必要がない

• 24時間365日の可用性をベンダー任せにしたい

判断フロー

5つの質問で方向性が決まります。

質問2でNoが出た時点で、機能比較の結果にかかわらずIDaaSに寄せるのが安全です。運用されない認証基盤は、機能が足りている状態より危険だからです。

本番運用で詰まりやすいポイント

検証環境では動いたのに本番で問題になる、という典型パターンがあります。公式の本番構成ガイドにも記載がありますが、実務で繰り返し見かけるものを挙げます。

開発用のデータベース設定のまま本番に出す

Keycloakには組み込みのH2データベースが同梱されていますが、これは開発用途に限定されたものです。公式ドキュメントでも本番環境での使用は想定されていません。本番ではPostgreSQLやMySQLなどの外部データベースを用意します。

PostgreSQLの選定基準は「PostgreSQLとは？特徴・MySQLとの違い・案件単価・将来性をフリーランス視点で解説」で整理しています。認証基盤のDBは、可用性とバックアップの要件がアプリ本体より厳しくなる点に注意してください。ここが落ちると全アプリのログインが止まります。

アップグレード計画を立てていない

コミュニティ版はマイナーリリースが年4回程度のペースで出て、修正が入るのは基本的に新しい版です。つまり3か月ごとに「上げるか、据え置くか」の判断が発生します。

実務では、次のような運用ルールを最初に決めておくと破綻しにくくなります。

• リリースノートの確認担当と、確認するタイミングを決める

• 検証環境で先に上げ、アプリ側のアダプタとの互換性を確認する

• メジャーバージョンをまたぐ場合は、公式のアップグレードガイドの差分を必ず読む

• 何バージョンまで遅れを許容するかの上限をあらかじめ決めておく

長期のサポート期間が必要で、かつ追従の工数を割けない場合は、RHBKの契約が現実的な選択肢になります。

可用性とクラスタ構成

本番では、1台構成だとそのサーバーの停止が全アプリのログイン停止に直結します。複数インスタンスを立て、セッション情報を共有する構成が基本です。KeycloakはInfinispanによる分散キャッシュを使ってこれを実現します。

Kubernetes上で運用する場合はOperatorを使う構成が取りやすく、OpenShift環境であればRHBKとの組み合わせが選択肢になります。コンテナ基盤側の前提は「Kubernetesとは？仕組み・Dockerとの違い・フリーランス案件の単価をエンジニア視点で解説」「OpenShift案件の単価相場｜必要スキル・参入ルートとRancher比較」が参考になります。

カスタマイズしすぎてアップグレードできなくなる

KeycloakはSPI（Service Provider Interface）による拡張やテーマのカスタマイズができます。柔軟な反面、内部APIに依存した拡張を作り込むと、バージョンアップのたびに修正が必要になります。

作り込む前に、「標準機能の組み合わせで要件を満たせないか」をもう一度検討する価値があります。独自実装の量は、そのままアップグレード時の負債になります。

ミニFAQ：運用

Q. アップグレードはどのくらいの頻度で計画すべきですか。

コミュニティ版なら、マイナーリリースが年4回程度出る前提で、四半期ごとに判断の機会を設けるのが無理のない形です。毎回上げる必要はありませんが、判断を先送りし続けると差分が大きくなり、一度の作業量が跳ね上がります。

Q. 認証基盤の監視では何を見ればいいですか。

ログインの成功・失敗率、レスポンスタイム、トークン発行数、データベース接続数が基本です。認証は「遅い」だけでも全アプリの体験を悪化させるため、死活監視だけでは足りません。

既存IdPからの移行パターン

移行には主に3つのパターンがあります。

段階移行を選ぶ場合、Keycloakのアイデンティティブローカリング機能が中心になります。ユーザーから見ればログイン先はKeycloakですが、裏側では旧IdPに認証を投げている状態です。旧IdPの契約を切れるのは全ユーザーの移行が終わった後になるため、移行期間中は両方の費用がかかる点を見込んでおきます。

RH-SSOからの移行については、Red Hatが公式のマイグレーション手順を提供しています。バージョンをまたぐ場合は、間のメジャーバージョンごとの差分確認が必要です。

Keycloakを扱うエンジニアに求められるスキル

Keycloakの実務では、アプリ側とインフラ側の両方の知識が要求されます。

• プロトコルの理解：OpenID Connect、OAuth 2.0、SAML 2.0の仕様と使い分け

• トークンの扱い：JWTの構造、署名検証、有効期限とリフレッシュの設計

• インフラ構築：コンテナ、データベース、TLS、ロードバランサ

• 既存ディレクトリとの連携：LDAP／Active Directoryの構造理解

• セキュリティ設計：セッション固定やリダイレクトURIの検証といった攻撃面の理解

ゼロトラストの文脈で認証基盤を刷新する案件もあり、その場合は境界型防御との考え方の違いを押さえておくと設計の議論がしやすくなります。「ゼロトラストとは｜境界型との違い・主要技術・案件動向を解説」で基本的な整理をしています。

認証基盤まわりの案件動向や単価水準については「認証基盤・IDaaSエンジニアのフリーランス案件動向｜単価・必要スキル・主要製品」で扱っています。自分のスキルセットでどの程度の単価を狙えるか確認したい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を把握できます。セキュリティ領域全体のレンジ感は「セキュリティエンジニアのフリーランス単価相場｜案件動向とスキル別レンジ」が参考になります。

まとめ

Keycloakを選ぶかIDaaSを選ぶかは、機能比較ではなく認証基盤の運用を自社で引き受けるかどうかで決まります。ライセンス費がゼロでも、アップグレードと障害対応の工数は消えません。

要点を整理します。

• KeycloakはOIDC・OAuth 2.0・SAML 2.0に対応したOSSのIAM基盤で、SSO・MFA・外部IdP連携・LDAP連携を標準で備える

• Auth0・Oktaとの本質的な違いは責任範囲。可用性とパッチ適用を誰が持つかで判断する

• コミュニティ版は長期サポート前提の提供形態ではない。年4回程度のマイナーリリースに追従する運用計画が前提になる

• 商用サポートが必要ならRed Hat build of Keycloakという第3の選択肢がある

• 「3年後も認証基盤を見られる人がいるか」がNoなら、他の条件にかかわらずIDaaSに寄せるほうが安全

• 本番では外部データベースと複数ノード構成が前提。開発用の同梱データベースのまま本番に出さない

要するに、運用体制を持てるならKeycloak、持てないならIDaaSが基本線です。

次のステップとしては、まず開発環境でKeycloakを起動し、自社アプリを1つクライアントとして登録してみるのが早道です。そのうえで、この記事の判断フローの5つの質問に自社の状況を当てはめてください。機能が足りるかどうかは、たいていの場合ボトルネックになりません。

参照した一次情報は以下のとおりです。

• Keycloak公式サイト

• Keycloak ダウンロード（最新安定版の確認）

• Keycloak 本番環境の構成ガイド

• CNCF Keycloak プロジェクトページ

• Red Hat build of Keycloak 製品ページ

• Auth0 料金ページ