Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】

Keycloak（キークローク）は、ログイン・シングルサインオン（SSO）・多要素認証といった「認証・認可」をまとめて担うオープンソースの認証基盤です。比較相手としてよく挙がるのがOktaで、ほかにAuth0やAmazon Cognitoも候補に入ります。「自前で持つか、マネージドに任せるか」が導入判断の分かれ目ですが、実務ではOktaを社員のIdPとして残したままKeycloakを手前に置く併用構成も珍しくありません。この記事では、Keycloakの基礎とメリット・デメリット、Oktaとの違い、OktaをKeycloakに連携する設定手順とコード、4製品の比較表と料金、Dockerでの起動、日本語化、脆弱性とサポートの選び方までを、2026年10月12日・16日に確認した公式ドキュメントと料金ページ、そして最新版26.8.1を手元のDockerで動かした結果をもとに整理します。

まとめ：KeycloakとOktaの選び分けは「自前運用か委託か」、併用も可能

• Keycloakが向く：ライセンス費用をかけず認証基盤を持ちたい／オンプレや自社クラウドにセルフホストしたい／認証フローやログイン画面を細かく作り込みたい／既存のLDAP・Active Directoryと統合したい組織。
• Oktaが向く：社員向けのSSOとMFAを、サーバー運用なしで早く整えたい組織。Okta Workforce Identityは1ユーザー月額6ドルのStarterからで、年間契約の最低額は1,500ドルです（2026年10月時点の公式料金ページ）。
• Auth0が向く：自社サービスの会員ログインを、開発者向けのSDKとマネージド環境で素早く作りたい組織。Auth0は2021年にOktaが買収した顧客ID向けのIDaaSです。買収後の位置づけと料金の数え方の違いはAuth0とOktaの違い: 顧客IDと従業員IDで分かれる選定基準と料金・実装の判断で整理しています。
• Amazon Cognitoが向く：すでにAWS中心で構築しており、AWSサービスと密に連携したい組織。
• 併用という第三の道：社員の認証はOktaのまま、自社アプリ群の認可や顧客向けログインはKeycloakに集める構成が取れます。KeycloakはOktaをOpenID Connect（OIDC）のIDプロバイダーとして登録でき、Keycloak側の登録はkcadm.shのコマンド1本で済み、ほかにOkta側のアプリ統合の作成とログインの確認が要ります。

KeycloakはApache License 2.0で無償・商用利用も可能な代わりに、構築・運用・セキュリティ更新を自分たちで担う必要があります。ライセンス費はゼロでも、サーバー代と運用の人件費はかかります。

Keycloakとは：Red Hat発のOSS認証基盤（IAM）の仕組みと26.8系の現状

Keycloakは、WebアプリケーションやAPIに対して認証（誰がアクセスしているか）と認可（何にアクセスしてよいか）を提供する、オープンソースのアイデンティティ／アクセス管理（IAM）ソフトウェアです。読み方は「キークローク」。Red Hatが主導して2014年に初版が公開され、2023年4月10日にはCNCF（Cloud Native Computing Foundation）のIncubatingプロジェクトとして受理されました。ライセンスはApache License 2.0で、無償かつ商用利用が可能です。

業界標準のOAuth 2.0・OpenID Connect・SAML 2.0に対応しており、認証機能を一から実装せずに、SSOやソーシャルログイン、多要素認証などを短期間で組み込めるのが最大の特徴です。Javaで動作し、Quarkusベースのディストリビューションに刷新されてから起動も高速になりました。2026年10月16日時点の最新版はGitHubで2026年10月13日に公開された26.8.1です。機能面の節目は10月1日の26.8.0で、SCIM APIとクライアントシークレットのローテーションが正式サポートに昇格しました。26.8.1はセキュリティ修正が中心のパッチ版です。

プロトコルの基礎はOAuth 2.0とは？仕組み・認可フローと認証との違い、OAuth 2.1の変更点をわかりやすく解説やOIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説もあわせてご覧ください。なお本記事はOkta・Auth0・Cognitoとの比較と導入判断に特化しているため、管理コンソールの操作やDB設定、権限モデルの詳しい使い方はKeycloakのデータベース設定と使い方｜PostgreSQL接続・対応DB・バックアップから権限モデルまでで扱っています。

Keycloakの主な機能：SSO・MFA・外部IdP連携・レルム

Keycloakが標準で備える代表的な機能は次のとおりです。いずれも管理コンソール（GUI）、管理用CLIの kcadm.sh、またはAdmin REST APIから設定できます。

• シングルサインオン（SSO）：一度のログインで連携する複数アプリにアクセス可能。OIDC／SAMLで実現します。SSOの実現方式そのものはシングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定を実装手順で解説で比べています。
• 多要素認証（MFA）：ワンタイムパスワード（OTP）を標準サポート。WebAuthn／パスキー（Passkey）にも対応し、ログイン画面に統合されています。
• ロールベースアクセス制御（RBAC）：ユーザーにロールを割り当て、アプリ内の操作範囲を制御。
• ソーシャルログイン／IdP連携（Identity Brokering）：Google・GitHubなどのログインに加え、OktaやMicrosoft Entra IDのような外部IdPをOIDCまたはSAMLで仲介できます。後半の連携手順はこの機能を使います。
• 金融・機器向けの標準規格：OAuth 2.0／OIDCの拡張であるFAPI、別端末で認証を承認するCIBA、入力手段の乏しい機器向けのDevice Authorization Grantにも対応。日立製作所のKeycloak紹介ページは、これらとWebAuthn・パスキー対応の開発を日立が主導したと説明しています。
• LDAP・Active Directory連携：User Federation機能で既存のユーザー管理と統合。
• レルム（Realm）：ユーザーや設定を分離して管理する単位。1インスタンスで複数テナント／環境を分離できます。
• SCIM API：26.8.0で正式サポートになったユーザー・グループの自動プロビジョニング用API。仕組みはSCIMとは？ID自動プロビジョニングの仕組みとエンドポイント実装を解説を参照してください。

Keycloakが使われる主なユースケース：社内SSOからB2B SaaSの認可まで

Keycloakは規模や業種を問わず採用されています。代表的な使われ方は次のとおりです。

• 社内システムの統合SSO：勤怠・ドキュメント共有・チャットなど複数の社内ツールを一度のログインで横断利用。既存のActive DirectoryやLDAPと連携して、現在のユーザー管理を活かしたまま導入できます。
• B2B向けSaaSのマルチテナント：レルムを顧客企業ごとに分ければ、ユーザー・認証フロー・IdP設定まで丸ごと分離できます。1つのレルムの中で顧客企業ごとのメンバーやIdPをまとめたい場合はOrganizations機能を使います。テナントごとに認証ルールやブランディングを変えられます。顧客企業が使うOktaやEntra IDをテナント単位でIdPとして登録すれば、顧客側のアカウントでそのままログインしてもらえます。
• BtoCサービスのソーシャルログイン：GoogleやLINEなどのアカウントでログインできるようにし、会員登録のハードルを下げて離脱を防ぎます。
• API・マイクロサービスの認可基盤：OAuth 2.0／OIDCのトークンを発行し、複数サービス間で統一した認可を実現します。

Keycloakのメリット・デメリット：ライセンス無償と引き換えの運用責任

導入判断に直結するメリット・デメリットを整理します。

要点は、初期費用を抑えつつ高度な機能を使える一方で、構築・運用・セキュリティ更新の責任を自社が負う点にあります。商用IDaaSでは基盤そのものの更新や性能調整をベンダーが担い、利用側に残るのはアプリ連携や設定の検証です。Keycloakではバージョンアップ時の互換性確認やパフォーマンスチューニングまで自社の作業になります。26系はおおむね月2回のペースで新版が出ており、2026年8月5日の26.7.1から10月13日の26.8.1までの約10週間で7本が公開されました。更新を追い続ける体制を用意できるかどうかが、採用可否の分かれ目になります（中身は後述の脆弱性の章で扱います）。

KeycloakとOktaの違い：OSSのセルフホストと従業員向けIDaaSの比較

「keycloak okta」で調べる人の多くは、どちらを選ぶか、または両方をどうつなぐかで迷っています。両者はどちらもOIDC・SAMLに対応したIdPになれますが、製品としての成り立ちはそれぞれ異なるものです。Oktaの機能と認証の仕組みそのものはOkta（オクタ）とは？認証の仕組み・機能・料金・セキュリティを2026年版で解説で詳しく扱っているので、ここではKeycloakと並べたときの差に絞ります。

料金の数え方の違い：ライセンス0円と1ユーザー月額6ドルからの差

Oktaの公式料金ページでは、Workforce Identityのスイートが1ユーザー月額でStarter 6ドル、Core Essentials 14ドル、Essentials 17ドル、ProfessionalとEnterpriseは要問い合わせと示されています（2026年10月12日確認、すべて年額払い）。最低契約額は年間1,500ドルです。社員300人でStarterなら年間21,600ドル、Essentialsなら年間61,200ドルが一つの目安になります。

Keycloakはこのライセンス費がゼロになる代わりに、サーバー代と運用の人件費が乗ります。冗長構成の仮想マシン2台と外部DB、監視、月2回前後の新版の検証と適用を見積もります。少人数の組織では、その人件費とサーバー代の合計がOktaの年間最低額1,500ドルや人数分のライセンス費を上回るかどうかで比べてください。逆に、数千人規模の利用者がいる、あるいは顧客向けログインで利用者数が読めない場合は、ユーザー数に比例しないKeycloakの費用構造が効いてきます。

KeycloakとOktaの運用責任の違い：パッチ適用と可用性の担い手

Oktaでは認証基盤の稼働監視、脆弱性対応、機能更新をOkta側が担います。管理者がやるのはアプリ連携とポリシー設定です。Keycloakではこれらがすべて自社の仕事になり、認証基盤が止まれば連携している全アプリにログインできなくなります。Keycloak公式の本番構成ガイドも、TLSの必須化、公開エンドポイントと管理系の分離、リバースプロキシの設置、データベースの選定を本番の前提として挙げています。この運用を引き受ける人員がいるかどうかによって、ライセンス費の差額をどう評価するかも変わるのです。

Keycloak・Auth0・Okta・Cognito比較表と2026年10月の料金

商用IDaaSを含む4製品の違いを一覧にしました。料金は2026年10月12日に各社の公式ページで確認した値で、為替や改定で変わります。Auth0側の実額とMAU課金の増え方はAuth0の料金はいくら？MAU課金の実額と無料枠を超えた後の増え方を解説で帯ごとに並べています。

Auth0の料金ページではFreeプランが月間アクティブユーザー（MAU）2万5,000人まで、有料のB2C Essentialsは500 MAUで月額35ドルからです。Amazon Cognitoの料金ページでは、Liteティアに月1万MAUの無料枠があり、超えた分は最初の9万MAUが1MAUあたり0.0055ドル、Essentialsティアは無料枠1万MAUの後に0.015ドルです。なお外部IdPとのSAML／OIDCフェデレーションでサインインする利用者は、月50MAUを超えると1MAUあたり0.015ドルかかる別枠の計算になります。

判断の軸は単純で、運用負荷を自社で引き受けてでも自由度とコストを取るならKeycloak、運用を任せて立ち上げ速度を取るならAuth0・Okta・Cognitoです。AWS中心の構成なら、AWSと統合しやすいAmazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説も有力な選択肢になります。なお商用の手厚いサポートが必要な場合は、Keycloakをベースにした商用版「Red Hat build of Keycloak（RHBK）」という選択肢もあります。保守期間やライセンスの数え方の違いはRed Hat build of KeycloakとOSS版の違いで整理しています。

Keycloakの脆弱性とサポート：26.8.1のセキュリティ修正とLTSの有無

Keycloakは全アプリのログインの入口なので、脆弱性によっては認証回避や権限昇格に直結します。26.8.1の修正一覧には、閲覧権限のないグループ情報が見えてしまうものや、メトリクスの系列が際限なく増えるものも含まれ、影響の種類はさまざまです。導入前に「どのくらいの頻度で、どんな種類の修正が出るのか」と「古い版を誰が直してくれるのか」を押さえておくと、運用体制の見積もりがぶれません。

26.8.1の修正内容：Security fixes欄22項目のうち19項目にCVE番号

26.8.1のリリースノートでは「Security fixes」欄に22項目が並び、そのうち19項目にCVE番号が付いています。対象は外部IdPの仲介（Identity Brokering）、管理APIの細かな権限設定、認可サービス、2要素認証の設定強制、PAR（Pushed Authorization Requests）と、認証の中核に広く及びます。後半で扱うOkta連携に直接関わるのは次の2件です。

• CVE-2026-15943：OIDCのIdP設定を更新するとき、Client Secretをマスク値のまま送ってtokenUrlを書き換えると、保存済みの本物のシークレットが新しい送信先に引き継がれていた。IdPの管理権限を持つ委任管理者が、シークレットを任意のトークンエンドポイントへ送らせることができる（Issue #50945）。
• CVE-2026-18569：OIDCのIdPで署名検証（validateSignature）を無効にしていると、バックチャネルログアウトが署名のない（alg=none）ログアウトトークンを受け付け、第三者が仲介ユーザーを強制ログアウトさせられた（Issue #51381）。

どちらも26.8.1で修正済みです。外部IdPを使っているなら26.8.1以上へ上げ、後述のkcadm.shの例のとおり validateSignature は有効のままにしてください。公開済みの勧告はGitHubのSecurity Advisoriesで一覧でき、2026年に入ってからも6月26日に8件、8月6日に7件がまとめて公開されました。9月16日に公開されたリプレイ保護の回避（CVE-2026-90997）は深刻度High・CVSS 3.1で7.4で、26.7.0以上26.7.4未満を、MySQL／MariaDBとstatelessモードの組み合わせで使っている構成が影響を受けます。

サポートの選択肢：コミュニティ版は最新版のみ、長期サポートはRed Hat build of Keycloak

コミュニティ版には長期サポート（LTS）がありません。2026年9月11日に開かれた公式のIssue #52656は冒頭で「Keycloak currently only supports the latest release.」と現状を書き、新しいメジャー版やマイナー版が出たら修正を受け取るには直ちに上げるしかない、と課題を整理しています。LTSや複数版の並行サポートはこのIssueで検討中の段階です。つまり26.8.1が出た時点で、26.7系に追加の修正が出ることは前提にできません。

旧版に留まりながら修正を受けたい場合の選択肢は、Red Hatのサブスクリプション製品であるRed Hat build of Keycloak（RHBK）です。RHBKのライフサイクル方針では、メジャー系列全体のフルサポートとメンテナンスの期間を26.xで最低2年、27.x以降で最低3年としています。個々のマイナー版は、コミュニティ版の偶数マイナー（26.0、26.2、26.4など）をもとに約6か月ごとに出て、2つ後のマイナー版が出るまでの約12か月間、修正版が提供されます。2026年10月16日時点の構成一覧で最も新しい系列は26.6で、9月16日には26.6.7のセキュリティ更新（RHSA-2026:68278）が出ています。

国内では、Keycloakのメンテナーを擁する日立製作所が、Keycloakのサポートや技術支援のサービスを提供していると自社の紹介ページで案内しています。判断の目安は単純です。月2回前後の更新を自力で検証・適用できるならコミュニティ版、できないならRHBKか支援ベンダーとの契約、どちらも難しいならOkta・Auth0・CognitoのようなマネージドのIDaaSを選んでください。

Keycloakを試すDocker起動手順：26.8.1の開発モード

最も手軽なのはDockerでの起動です。公式のDocker入門ページ（2026年10月16日確認）では26.8.1のイメージを使う次のコマンドが示されており、これで開発用サーバーが立ち上がります。

docker run -p 127.0.0.1:8080:8080 \
  -e KC_BOOTSTRAP_ADMIN_USERNAME=admin \
  -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin \
  quay.io/keycloak/keycloak:26.8.1 start-dev

2026年10月16日にこのコマンドを実行したところ（colima上のDocker 29.5.2、Ubuntu 24.04のx86_64仮想マシン、イメージは取得済み）、起動ログに「Keycloak 26.8.1 on JVM (powered by Quarkus 3.40.1) started in 22.902s」と出ました。docker run からこの行が出るまでの壁時計は約46秒です。同じログには、identity-brokering-api:v1 などの非推奨機能が既定で有効になっている旨の警告が出ます。

起動後、ブラウザで http://localhost:8080 を開き、上で指定した管理者ユーザーでログインします。26系では一時管理者の作成に KC_BOOTSTRAP_ADMIN_USERNAME / KC_BOOTSTRAP_ADMIN_PASSWORD を使います（古い記事にある KEYCLOAK_ADMIN 系の環境変数は現行では非推奨です）。ZIP版の入門ページの手順で動かす場合は、次のように起動します。

bin/kc.sh start-dev \
  --bootstrap-admin-username admin \
  --bootstrap-admin-password admin

動作にはJavaが必要です。ZIP版の入門ページはOpenJDK 25を前提にしており、リリースノートでは26系でOpenJDK 25への対応が追加された一方、公式コンテナイメージはFIPSモード対応のためOpenJDK 21のままと説明されています。実際に26.8.1のコンテナで java -version を実行すると、OpenJDK 21.0.12.1と表示されました。OpenJDK 17は非推奨で、将来のリリースで削除予定です。なお start-dev はTLS無効など開発向けの設定のため、本番環境では start コマンドとHTTPS・本番DB（PostgreSQLなど）を用いた構成にしてください。

開発モードから本番運用（構築）へ進む際は、最低限おさえておきたい設定があります。いずれもコマンドライン引数または設定ファイルで指定します。

• 起動コマンド：start-dev ではなく start を使う。事前にビルドしたイメージなら --optimized を付けて起動を速くする。
• HTTPS必須：--https-certificate-file などでTLS証明書を設定する。リバースプロキシの背後に置く場合は、プロキシが付ける転送ヘッダーに合わせて --proxy-headers xforwarded か --proxy-headers forwarded を指定する。プロキシでTLSを終端してKeycloakへHTTPで転送する構成（エッジ終端）では --http-enabled true も必要（リバースプロキシのガイド）。26.8.0からは暗号化したPEMファイルの証明書・秘密鍵も扱える。
• 本番DB：開発用の組み込みDBではなく、--db postgres のように外部DB（PostgreSQLなど）と接続情報を指定する。
• ホスト名：--hostname で公開URLを明示し、リダイレクトやトークン発行のURLを正しく揃える。Oktaなど外部IdPと連携するときは、ここで決めたホスト名がリダイレクトURIに入る。
• 冗長化・運用：複数ノードでのクラスタ構成、ヘルスチェック（health-enabled）の有効化、バージョン更新時の移行確認を計画する。

KeycloakにOktaをOIDCのIdPとして連携する手順とkcadm.shの設定例

ここからは、社員のアカウントはOktaに置いたまま、Keycloakのログイン画面に「Oktaでログイン」を出す構成を作ります。KeycloakのIdentity Brokering機能でOktaを外部IdPとして登録し、利用者がOktaで認証してからKeycloak経由でアプリに入る仕組みです。手順はKeycloak管理ガイドのOpenID Connect v1.0 identity providersの章（26.8.1時点の最新版）と、Okta側の公式ヘルプに沿っています。前章のDockerで起動した localhost:8080 のKeycloakと、Oktaの開発者用または検証用テナントがあれば試せます。

手順1：Okta管理コンソールでOIDCアプリ統合を作成しリダイレクトURIを登録

Oktaのヘルプ「Create OpenID Connect app integrations」のとおり、Admin Consoleで「Applications」から「Create App Integration」を選び、サインイン方式に「OIDC - OpenID Connect」、アプリ種別に「Web Application」を選びます。Sign-in redirect URIには、Keycloakが外部IdPからの応答を受け取るURLを登録します。形式は http://localhost:8080/realms/demo/broker/okta/endpoint で、demo がレルム名、okta が手順3で付けるIdPの別名（alias）です。Oktaのヘルプはサブドメインのワイルドカード利用を避けるよう案内しているので、本番では確定したホスト名で登録します。作成後に表示されるClient IDとClient Secretを控えておきます。

手順2：Oktaのディスカバリ文書でのエンドポイント確認

Okta developer docsの認可サーバーの解説によると、Org認可サーバーのissuerは https://{yourOktaDomain}、OIDCのディスカバリ文書は https://{yourOktaDomain}/.well-known/openid-configuration です。カスタム認可サーバーを使う場合はパスに /oauth2/{authorizationServerId} が入ります。KeycloakからOktaへ社員のログインを任せるだけなら、Org認可サーバーで対応可能です。手元で次のように確かめ、出力された値を手順3に貼ります。

export OKTA_DOMAIN=dev-123456.okta.com   # 自社のOktaドメインに置き換える
curl -s "https://${OKTA_DOMAIN}/.well-known/openid-configuration" \
  | jq '{issuer, authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri}'

手順3：kcadm.shによるOktaのIDプロバイダー登録

管理コンソールの「Identity providers」から「OpenID Connect v1.0」を選んで画面で設定してもかまいませんが、環境ごとに同じ設定を再現するにはCLIが確実です。管理ガイドには、汎用OIDCプロバイダーは providerId を oidc にし、authorizationUrl・tokenUrl・clientId・clientSecret を指定すると書かれています。kcadm.shはコンテナ内の /opt/keycloak/bin にあるので、コンテナに入ってパスを通し、手順1・2で控えた値を環境変数に入れてから実行します。URLは手順2の出力に合わせて差し替えてください。

# Keycloakのコンテナに入る（コンテナ名は docker ps で確認）
docker exec -it <コンテナ名> bash

# ここからコンテナ内。kcadm.shにパスを通し、手順1・2の値を設定する
export PATH=$PATH:/opt/keycloak/bin
export OKTA_DOMAIN=dev-123456.okta.com      # 自社のOktaドメイン
export OKTA_CLIENT_ID=<OktaのClient ID>
export OKTA_CLIENT_SECRET=<OktaのClient Secret>

# 管理者としてログインし、検証用のレルムを作る
kcadm.sh config credentials --server http://localhost:8080 --realm master --user admin --password admin
kcadm.sh create realms -s realm=demo -s enabled=true

# OktaをOIDCのIDプロバイダー（alias=okta）として登録する
kcadm.sh create identity-provider/instances -r demo \
  -s alias=okta -s providerId=oidc -s enabled=true \
  -s displayName=Okta \
  -s config.issuer=https://${OKTA_DOMAIN} \
  -s config.authorizationUrl=https://${OKTA_DOMAIN}/oauth2/v1/authorize \
  -s config.tokenUrl=https://${OKTA_DOMAIN}/oauth2/v1/token \
  -s config.userInfoUrl=https://${OKTA_DOMAIN}/oauth2/v1/userinfo \
  -s 'config.useJwksUrl="true"' \
  -s config.jwksUrl=https://${OKTA_DOMAIN}/oauth2/v1/keys \
  -s 'config.validateSignature="true"' \
  -s 'config.defaultScope="openid profile email"' \
  -s config.clientId=${OKTA_CLIENT_ID} \
  -s config.clientSecret=${OKTA_CLIENT_SECRET}

# 登録内容を確認する
kcadm.sh get identity-provider/instances -r demo --fields alias,providerId,enabled

このコマンド列を26.8.1の新しいコンテナで空のシェルから順に実行すると「Created new instance with id ‘okta’」と返り、続く get で alias・providerId・enabled を確認できました。Oktaのドメインとクライアント情報はダミー値で試しており、登録自体はOktaに接続しなくても通ります。取得し直したClient Secretは ********** とマスクされて返ります。26.8.0以前では、このマスク値のままtokenUrlだけを書き換えると本物のシークレットが新しい送信先へ渡っていた（前述のCVE-2026-15943）ので、エンドポイントを変えるときはシークレットも入れ直してください。

既定の設定では、KeycloakからOktaへの認可リクエストにPKCEの code_challenge が付きません。PKCEを併用したい場合は kcadm.sh update identity-provider/instances/okta -r demo -s 'config.pkceEnabled="true"' -s config.pkceMethod=S256 を実行します。実行後のリクエストには code_challenge_method=S256 が付きました。

Client Secretをシェル履歴に残したくない場合は、環境変数を別ファイルから読み込むか、管理コンソールで後から入力します。社員のメールアドレスをOkta側で検証済みとして扱うなら、IdP設定の「Trust Email」をONにすると、Keycloak側でのメール確認を省けます。

手順4：ログイン画面とkc_idp_hintによるOkta経由のSSO確認

http://localhost:8080/realms/demo/account を開くと、ログイン画面に「Okta」のボタンが出ます。このボタンを押すとOktaのサインイン画面に移り、認証後にKeycloakへ戻る流れです。初回はFirst login flowが動き、Keycloak側にユーザーが作られます。ボタンを出さずにOktaへ直行させたい場合は、アプリの認可リクエストに kc_idp_hint=okta を付けてください。管理ガイドでは、IdP設定の「Hide on Login Page」をONにしてもこのパラメータで呼び出せると説明されています。26.8.1で確かめると、kc_idp_hint=okta 付きの認可リクエストはKeycloakのログイン画面を出さずに /realms/demo/broker/okta/login へ303で転送され、そこからOktaの /oauth2/v1/authorize へ、redirect_uri に手順1で登録したbroker/okta/endpointのURL、scope=openid profile email を付けて送られました（Okta側のサインインまでは行っていません）。OktaのグループをKeycloakのロールへ写すにはIdPのマッパーを追加しますが、26.8.0の更新ではIdPマッパー周りに非互換の変更が含まれるため、既存環境を上げる前にアップグレードガイドで確認してください。

OktaとKeycloakを併用・移行する3つの構成パターンと判断基準

「Keycloakか、Oktaか」の二択で考えると判断を誤りやすく、実際には次の3パターンのどれに当てはまるかで決めるほうが早く結論が出ます。

• パターンA：Oktaに一本化する。社員が使うSaaS（Microsoft 365、Google Workspace、Slackなど）へのSSOが主目的で、自社開発アプリは少ない場合です。Oktaの連携カタログで済む範囲が広く、認証基盤の運用要員を置かずに済みます。自社アプリが数本ならOktaにOIDCアプリとして直接登録すれば足ります。
• パターンB：Oktaを上流IdP、Keycloakを下流の認可基盤にする。社員はOktaで認証し、自社アプリ群のロール・クライアント・トークンの中身はKeycloakで管理します。自社アプリが多い、アプリごとに独自のクレームやロールを載せたい、Okta側のアプリ登録を増やしたくない、という場合に向きます。前章の手順はこの構成です。
• パターンC：顧客向けはKeycloak、社員向けはOkta。顧客の会員ログインは利用者数が読めず、ユーザー課金だと費用が膨らみやすい領域です。ここをKeycloakで持ち、社員の業務SaaSはOktaに任せます。顧客向けをマネージドにしたい場合はAuth0やCognitoが代わりの候補になります。

見送りの条件も明確にしておきます。認証基盤を24時間止めずに運用する人員を確保できない、あるいはパッチ版の追従を外注に頼る予算がないなら、パターンBとCは採らずにパターンAかマネージドのIDaaSで始めるべきです。反対に、Oktaからの移行を考えている場合も、いきなり全面移行するよりパターンBで一度Keycloakを下流に挟み、アプリ側の接続先をKeycloakへ揃えてから上流IdPを差し替えるほうが、利用者への影響を小さくできます。IDaaS全般の位置づけはIDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説、SAMLでつなぐ場合の注意点はSAMLとは？認証フロー・IdP/SPの仕組みとOAuth・OIDCとの使い分けを実装視点で解説が参考になります。

認証基盤は、一度入れると全アプリの接続先になるため、後から差し替えるほど手戻りが大きくなります。Keycloakの構築・Oktaとの連携設計・既存IdPからの移行計画まで含めて相談したい場合は、認証基盤・ID管理システム開発のページで支援範囲を紹介しています。

KeycloakのUIを日本語化する方法：レルムの国際化設定とテーマの翻訳ファイル

Keycloakのログイン画面やアカウント画面は日本語に切り替えられます。翻訳ファイルは標準で同梱されており、26.8.1のテーマjar（org.keycloak.keycloak-themes-26.8.1.jar）には account・login・email・admin の4種類それぞれに messages_ja.properties が入っていました。必要なのはレルム側の設定です。

注意したいのは、ブラウザの言語設定を日本語にするだけでは切り替わらない点です。26.8.1で新しく作ったレルムは国際化（Internationalization）が無効で、Accept-Language: ja を送ってもログイン画面のタイトルは「Sign in to demo」のままでした。初期状態のmasterレルムも同じく英語のままです。次のようにレルムの国際化を有効にし、サポート言語に日本語を加えます。

kcadm.sh update realms/demo -s internationalizationEnabled=true \
  -s 'supportedLocales=["ja","en"]' -s defaultLocale=ja

この設定後はログイン画面のタイトルが「demoにサインイン」になり、HTMLの lang も ja に変わりました。既定言語を英語に戻しても、サポート言語に ja が入っていれば、ブラウザが日本語を求めた利用者には日本語で表示されました。ただし公式ガイドの言語選択の順序では、画面の言語切り替えで選んだ言語、ユーザーのプロフィールの言語、クライアントが ui_locales で渡した言語、前回選んだ言語のCookieがAccept-Languageより優先されるため、それらがあればそちらに従います。管理コンソールで設定する場合は、レルム設定の「Localization」タブで同じ項目を指定します。

訳語を自社用語に合わせたい場合は、標準テーマをもとにカスタムテーマを作り、その中に翻訳ファイルやロゴ・CSSを置きます。ブランディングと日本語化を一度に済ませられる方法です。テーマのキャッシュが有効な通常の設定では、変更後に再起動するか data/tmp/kc-gzip-cache を削除して反映します。開発中は --spi-theme--cache-themes=false などでキャッシュを切れば、再起動せずに編集を確認できます（テーマのガイド）。26.8.0ではログイン画面の外部IdPボタンのデザインが変わったため、カスタムログインテーマを使っている環境は、Oktaのボタン表示が崩れていないかを更新時に確かめてください。

ID統制（IGA）まで視野に入れる場合は、同じOSSのmidPointとは？オープンソースのIGA（ID統制）ツールを実装視点で解説で整理しています。Keycloak以外のセルフホスト型の選択肢として、APIファーストで多テナントを扱える製品はFusionAuthとは？Docker Composeでの起動手順とテナント設計・料金・Keycloakとの選び分けで比較しています。

よくある質問

Keycloakは商用利用しても無料ですか？

はい。Apache License 2.0のオープンソースで、ライセンス費用なしで商用利用できます。ただし構築・運用・セキュリティ更新は自社負担です。コミュニティ版は最新版しか修正されないため、旧版を長く使いたい場合や手厚いサポートが必要な場合は、マイナー版ごとに約12か月の修正提供があり、26.x系列全体では最低2年のサポートが定められたRed Hat build of Keycloakを検討します。

KeycloakとOktaはどちらを選べばよいですか？併用はできますか？

社員向けSaaSへのSSOが主目的で運用要員を置きたくないならOkta、自社アプリが多く認証フローや画面を作り込みたい、または顧客向けで利用者数が読めないならKeycloakが向きます。併用も可能で、KeycloakにOktaをOIDCのIDプロバイダーとして登録すれば、社員はOktaで認証したままKeycloak配下のアプリに入れます。

Auth0との一番の違いは？

Keycloakはセルフホスト型のOSS、Auth0（Okta傘下）はクラウド型のマネージドサービスです。Auth0はMAU課金で、Freeプランは2万5,000 MAUまで使えます（2026年10月時点）。自由度とコストを重視するならKeycloak、運用の手間を減らしたいならAuth0が向きます。

多要素認証（MFA）やパスワードポリシーは設定できますか？

ワンタイムパスワード（OTP）を標準でサポートし、WebAuthnやパスキー（Passkey）にも対応しています。特定のユーザーやクライアントにのみMFAを強制することも可能です。パスワードポリシーもレルム設定から最小文字数・文字種・履歴・有効期限などを細かく決められます。Oktaを上流IdPにする構成では、MFAをOkta側で済ませてKeycloak側では求めない設計も取れます。

Keycloakの構築は難しいですか？

試すだけならDockerで数分で起動できます。一方、本番運用ではHTTPS化・本番DB・冗長構成・バージョン更新などの設計が必要で、相応の運用スキルが求められます。まずは開発モードで触れ、Okta連携のような外部IdPの登録も検証レルムで試してから本番構成を検討するのがおすすめです。

関連記事

• Okta（オクタ）とは？認証の仕組み・機能・料金・セキュリティを2026年版で解説
• Keycloakのデータベース設定と使い方｜PostgreSQL接続・対応DB・バックアップから権限モデルまで
• Auth0とOktaの違い: 顧客IDと従業員IDで分かれる選定基準と料金・実装の判断
• Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説
• OIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説