リリースノート

今回のリリースでは、標準トークン交換のサポートを追加しました。トークン交換機能は長い間プレビュー版でしたが、ついに標準トークン交換をサポートできることを嬉しく思います。今のところ、これは トークン交換仕様 に準拠した内部トークンへの内部トークンの交換に限定されています。アイデンティティブローカリングやサブジェクトのなりすましに関連するユースケースはまだカバーしていません。今後のリリースでさらに多くのトークン交換ユースケースをサポートしたいと考えています。

詳細については、標準トークン交換 を参照してください。

以前の Keycloak バージョンで使用されていたレガシートークン交換からのアップグレード方法については、アップグレードガイド を参照してください。

このリリースでは、きめ細かい管理者権限の新しいバージョンが導入されました。バージョン 2 (V2) は、レルム内の管理アクセスに対する強化された柔軟性と制御を提供します。この機能により、管理者は広範な管理者ロールに依存せずに、ユーザー、グループ、クライアント、およびロールを管理するための権限を定義できます。V2 は、以前のバージョンと同じレベルのレルムリソースへのアクセス制御を提供し、将来のバージョンで機能を拡張する予定です。主なポイントは次のとおりです。

詳細については、きめ細かい管理者権限 を参照してください。

移行の詳細については、アップグレードガイド を参照してください。

役立つメトリクス名のリスト 可観測性ガイドカテゴリ に加えて、Grafana でこれらのメトリクスを表示する方法に関するガイドも含まれるようになりました。ガイド には 2 つのダッシュボードが含まれています。

複数のノードをクラスタリングするために、Keycloak は分散キャッシュを使用します。このリリース以降、すべての TCP ベースのトランスポートスタックで、ノード間の通信は TLS で暗号化され、自動生成された一時的な鍵と証明書で保護されます。

これにより、セキュアバイデフォルトのセットアップが強化され、新しいセットアップの構成手順が最小限に抑えられます。

詳細については、分散キャッシュガイドの トランスポートスタックのセキュリティ保護 を確認してください。

最適化またはカスタマイズされたイメージを使用する場合、古いイメージと新しいイメージに同じバージョンの Keycloak が含まれている場合、Keycloak Operator は新しいイメージのローリングアップデートを実行できるようになりました。これは、たとえば、ダウンタイムなしで更新されたテーマまたはプロバイダーをロールアウトする場合に役立ちます。

Operator でこの機能を使用するには、Auto アップデート戦略を有効にすると、Keycloak Operator はイメージの変更時に、ダウンタイムなしのローリングアップデートが可能かどうかを判断するために、古いイメージと新しいイメージを短時間起動します。この機能の詳細については、Keycloak Operator 高度な構成ガイドの ローリングアップデートの管理 セクションをお読みください。

ローリングアップデートが可能かどうかを判断するためのチェックは、Keycloak コマンドラインでも利用できるため、デプロイメントパイプラインで使用できます。コマンドラインで利用可能な機能の詳細については、アップデート互換性ツール ガイドをお読みください。

管理者イベント API は、以前の yyyy-MM-dd 形式に加えて、Epoc タイムスタンプに基づいてイベントをフィルタリングすることをサポートするようになりました。これにより、取得するイベントのウィンドウをよりきめ細かく制御できます。

direction クエリパラメータも追加され、返されるアイテムの順序を asc または desc として制御できるようになりました。過去には、イベントは常に desc 順 (最新のイベントが最初) で返されていました。

最後に、返されるイベント表現には、イベントの一意の識別子を提供する id も含まれるようになりました。

利用可能なすべてのログハンドラーが ECS (Elastic Common Schema) JSON 形式をサポートするようになりました。これにより、Keycloak の可観測性と集中ロギングのストーリーを改善するのに役立ちます。

詳細については、ロギングガイド を参照してください。

X.509 認証局で証明書を検証するために使用される証明書失効リスト (CRL) が、crl という名前の新しい Infinispan キャッシュ内にキャッシュされるようになりました。キャッシュにより、検証パフォーマンスが向上し、ソースごとに 1 つの CRL のみが維持されるため、メモリ消費量が削減されます。

新しいキャッシュプロバイダーのオプションを知るには、すべてのプロバイダー構成 ガイドの crl-storage セクションを確認してください。

Keycloak Operator は、デフォルトで、Keycloak の分散キャッシュに使用される内部ポートへのトラフィックを制限する NetworkPolicy を作成するようになりました。

これにより、セキュアバイデフォルトのセットアップが強化され、新しいセットアップの構成手順が最小限に抑えられます。

Kubernetes NetworkPolicy ルール構文を使用して、管理および HTTP エンドポイントへのアクセスをさらに制限できます。

詳細については、Operator 高度な構成 を参照してください。

https-management-certificates-reload-period オプションを設定すると、管理インターフェースの https-management-* オプションで参照されるキーストア、トラストストア、および証明書ファイルのリロード期間を定義できます。リロードを無効にするには -1 を使用します。デフォルトは https-certificates-reload-period で、デフォルトは 1 時間 (1h) です。

詳細については、管理インターフェースの設定 ガイドを確認してください。

リクエストされたスコープ、ACR (認証コンテキストクラス参照) などの条件に基づいて認証フローを動的に選択する機能が導入されました。これは、新しい AuthenticationFlowSelectorExecutor を新しい ACRCondition などの条件と組み合わせることにより、クライアントポリシー を使用して実現できます。詳細については、サーバー管理ガイド を参照してください。

最新バージョンのOpenID Connect Core Specificationでは、Client Authentication methods private_key_jwt および client_secret_jwt の JWT クライアントアサーションにおけるオーディエンス検証のルールが厳格化されました。Keycloak はデフォルトで、クライアント認証に使用される JWT トークンに単一のオーディエンスが存在することを強制するようになりました。

JWT クライアント認証における Keycloak バージョンの変更されたオーディエンス検証に関する情報は、アップグレードガイドを参照してください。

貢献してくれたThomas Darimont氏に感謝します。

これまで、User API を使用してユーザー資格情報をクエリすると、ユーザー・ストレージ・プロバイダーによって管理される資格情報は返されず、その結果、資格情報が最後に更新された日時のようなフェデレーション資格情報に関連付けられた追加メタデータを取得することができませんでした。

今回のリリースでは、レルム内の特定のユーザーに対してユーザー・ストレージ・プロバイダーが管理する資格情報を返せるように、新しいメソッド getCredentials(RealmModel, UserModel) を org.keycloak.credential.CredentialInputUpdater インターフェースに追加しました。これにより、ユーザー・ストレージ・プロバイダーは、資格情報が自身にリンクされているかどうかを示すとともに、管理コンソールを通じてユーザーを管理する際に、追加情報を表示できるように追加メタデータを提供できます。

LDAP の場合、標準の pwdChangedTime 属性、または Microsoft AD を使用している場合は pwdLastSet 属性に基づいて、パスワードが最後に更新された日時を確認できるようになります。

資格情報がローカル（Keycloak によって管理される）か、フェデレーションされているかを確認するには、CredentialRepresentation タイプと CredentialModel タイプの両方から利用可能な federationLink プロパティを確認できます。設定されている場合、federationLink プロパティは、特定のユーザー・ストレージ・プロバイダーに関連付けられたコンポーネントモデルの UUID を保持します。

Keycloak の送信リンク: レルムのメール設定[SMTP メール設定] で、トークン認証（XOAUTH2）がサポートされるようになりました。多くのサービスプロバイダー（Microsoft、Google）は SMTP OAuth 認証に移行しており、基本認証のサポートを終了しています。トークンはクライアントクレデンシャルグラントを使用して収集されます。

貢献してくれたSebastian Rose氏に感謝します。

新しい管理者設定が追加されました: クライアント → 詳細設定 → OpenID Connect 詳細設定 → 「アクセストークンヘッダータイプとして "at+jwt" を使用する」

有効にすると、アクセストークンは rfc9068#section-2.1 に準拠してヘッダータイプ at+jwt を取得します。それ以外の場合、アクセストークンヘッダータイプは JWT になります。

この設定はデフォルトでオフになっています。

貢献してくれたLaurids Møller Jepsen氏に感謝します。

検証可能な資格情報発行のための OpenID (OID4VCI) は、Keycloak では引き続き実験的な機能ですが、さらなる改善、特に入門方法が記載されたドキュメントが提供されました。

Keycloak OAuth SIG では、重要な開発と議論が行われています。Keycloak コミュニティの誰もが参加し、フィードバックを提供することを歓迎します。

この機能の開発と議論に参加してくれた OAuth SIG グループのすべてのメンバーに感謝します。特に、Awambeng Rodrick氏とIngrid Kamga氏に感謝します。

バージョン 26.1.1 では、資格情報リセットフロー後のデフォルトの動作を変更できるように、reset-credential-email（リセットメールの送信）オーセンティケーターに新しい構成オプションが追加されました。オプション force-login（リセット後にログインを強制）に 3 番目の構成値 only-federated が追加され、これはフェデレーションユーザーにはログインの強制が true であり、内部データベースユーザーには false であることを意味します。新しい動作がデフォルトになりました。このようにして、Keycloak と緊密に統合されていない可能性のあるユーザーフェデレーションプロバイダーによって管理されるすべてのユーザーは、問題を防ぐために資格情報リセットフロー後に再度ログインすることを強制されます。この動作の変更は、デフォルトでセキュアにするというポリシーによるものです。

詳細については、パスワード忘れを有効にするを参照してください。

X.509 オーセンティケーターには、証明書を検証するために CRL が構成されており、CRL が次回の更新フィールドで指定された時間内に更新されない場合にログインを中止する新しいオプション x509-cert-auth-crl-abort-if-non-updated（管理コンソールでは CRL が更新されていない場合は中止）があります。新しいオプションは、管理コンソールではデフォルトで true になっています。CRL 次回更新フィールドの詳細については、RFC5280、セクション 5.1.2.5 を参照してください。

以前の動作との互換性のために値 false が維持されています。既存の構成には新しいオプションがなく、このオプションが false に設定されているかのように動作しますが、管理コンソールは編集時にデフォルト値 true を追加することに注意してください。

reset-credential-email（リセットメールの送信）は、資格情報のリセットフロー（パスワード忘れ機能）で使用されるオーセンティケーターであり、リセット資格情報トークンリンクを含むメールをユーザーに送信します。このオーセンティケーターには、新しいオプション force-login（リセット後にログインを強制）が追加されました。このオプションが true に設定されている場合、オーセンティケーターはセッションを終了し、新しいログインを強制します。

この新しいオプションの詳細については、パスワード忘れを有効にするを参照してください。

Keycloak はデフォルトで、同じクラスターの他のノードを検出するためにデータベースを使用するようになり、特にクラウドプロバイダーの場合、追加のネットワーク関連の構成が不要になりました。また、クラウド環境ですぐに動作するデフォルトでもあります。

以前のバージョンの Keycloak では、クラスターを形成し、Keycloak のレプリケートされたキャッシュを同期するために、デフォルトとして UDP マルチキャストを使用して他のノードを検出していました。これには、マルチキャストが利用可能で、正しく構成されている必要がありましたが、通常、クラウド環境ではそうではありません。

このバージョンから、デフォルトは、Keycloak のデータベースを使用して他のノードを検出する jdbc-ping 構成に変更されました。これにより、マルチキャストネットワーク機能と UDP の必要がなくなり、TCP ベースの障害検出に動的ポートを使用しなくなるため、以前のデフォルトを使用していた環境にとって、簡素化とドロップイン置換になります。以前の動作を有効にするには、現在非推奨となっているトランスポートスタック udp を選択してください。

Keycloak Operator は引き続きトランスポートスタックとして kubernetes を構成します。

詳細については、分散キャッシュの構成ガイドを参照してください。

今回のリリースから、Keycloak は、OpenJDK 21 で実行している場合に、組み込みの Infinispan と JGroups の両方で仮想スレッドプールのサポートを自動的に有効にします（少なくとも 2 つの CPU コアが利用可能な環境の場合）。これにより、JGroups スレッドプールを構成する必要がなくなり、JGroups スレッドプールを HTTP worker スレッドプールに合わせる必要がなくなり、全体的なメモリフットプリントが削減されます。

以前のリリースでは、OpenTelemetry Tracing 機能はプレビューでしたが、現在は完全にサポートされています。つまり、opentelemetry 機能はデフォルトで有効になっています。

Keycloak のトレース機能には、複数の改善が加えられました。

詳細については、トレースの有効化ガイドを参照してください。

以前のリリースでは、--cache-config-file オプションが指定されていない場合、conf/cache-ispn.xml への変更はすべて無視されていました。

今回のリリースから、--cache-config-file が設定されていない場合、デフォルトの Infinispan XML 構成ファイルは conf/cache-ispn.xml になります。これは、現在および以前のリリースのドキュメントで示唆されている動作と、期待される動作の両方であるためです。

カテゴリ固有のログレベルを個別の log-level-category オプションとして設定できるようになりました。

詳細については、ロギングガイドを参照してください。

検証可能な資格情報発行のための OpenID (OID4VCI) は、Keycloak では引き続き実験的な機能ですが、今回のリリースで大幅に改善されました。この機能は、既存の構成の多くの洗練化と、機能をより動的かつカスタマイズ可能にすることから恩恵を受けています。

Keycloak OAuth SIG では、重要な開発と議論が行われています。Keycloak コミュニティの誰もが参加することを歓迎します。

この機能の開発と議論に参加してくれた OAuth SIG グループのすべてのメンバーに感謝します。特に、Francis Pouatcha氏、Ingrid Kamga氏、Pascal Knüppel氏、Thomas Darimont氏、Ogen Bertrand氏、Awambeng Rodrick氏、Takashi Norimatsu氏に感謝します。

オプション 最小 ACR 値 が、レルム OIDC クライアントの構成オプションとして追加されました。この追加は、ステップアップ認証に関連する拡張機能であり、特定のクライアントにログインする際に最小 ACR レベルを強制することを可能にします。

貢献してくれたSimon Levermann氏に感謝します。

ユーザー登録開始標準のサポートが追加されました。これにより、OIDC クライアントは、パラメーター prompt=create を指定してログインリクエストを開始し、既存のユーザーを認証するのではなく、新しいユーザーを登録する必要があることを Keycloak に通知できます。ユーザー登録の開始は、専用のエンドポイント /realms/<realm>/protocol/openid-connect/registrations を使用して Keycloak で既にサポートされていました。ただし、このエンドポイントは Keycloak 固有の独自ソリューションであったため、標準的な方法を優先して非推奨になりました。

貢献してくれたThomas Darimont氏に感謝します。

新しいオプション 証明書を生成 が、EC-DSA および Ed-DSA 鍵プロバイダーに存在します。レルム管理者によって生成された鍵が作成されると、この鍵の証明書が生成される場合があります。証明書情報は、管理コンソールと、レルム鍵を持つ JWKS エンドポイントから利用可能なこの鍵の JWK 表現で利用できます。

貢献してくれたPascal Knüppel氏に感謝します。

DPoP 鍵への認可コードバインディング のサポートが追加されました。これには、プッシュ認可リクエストによる DPoP のサポートが含まれます。

貢献してくれたTakashi Norimatsu氏に感謝します。

OIDC 認証リクエストは、最大長の追加カスタムパラメーターの数を制限してサポートします。追加パラメーターは、カスタム目的（たとえば、プロトコルマッパーを使用してトークンにクレームを追加するなど）に使用できます。以前のバージョンでは、パラメーターの最大数は 5 にハードコードされており、パラメーターの最大長は 2000 にハードコードされていました。現在、両方の値が構成可能です。さらに、追加パラメーターによってリクエストが失敗するか、パラメーターが無視されるかを構成することもできます。

貢献してくれたManuel Schallar氏とPatrick Weiner氏に感謝します。

Kubernetes デプロイのセキュリティを向上させるために、ネットワークポリシー を Keycloak CR で指定できます。Keycloak Operator は、トラフィックの送信元を定義するイングレスルールを受け入れ、必要なネットワークポリシーを自動的に作成します。

Microsoft AD を使用しており、管理インターフェースを通じてユーザーを作成する場合、ユーザーはデフォルトで有効として作成されます。

以前のバージョンでは、ユーザーに（一時的でない）パスワードを設定した後にのみユーザーのステータスを更新することができました。この動作は、他の組み込みユーザー・ストレージや、LDAP プロバイダーでサポートされている他の LDAP ベンダーと一貫性がありませんでした。

Condition - sub-flow executed および Condition - client scope は、Keycloak の新しい条件付きオーセンティケーターです。条件 Condition - sub-flow executed は、認証フローの実行中に以前のサブフローが正常に実行されたかどうか（または実行されなかったかどうか）を確認します。条件 Condition - client scope は、構成されたクライアントスコープが、認証を要求するクライアントのクライアントスコープとして存在するかどうかを確認します。詳細については、条件付きフローの条件を参照してください。

Keycloak の拡張機能を開発する場合、開発者は ProviderFactory インターフェースで dependsOn() メソッドを実装することにより、プロバイダーファクトリクラス間の依存関係を指定できるようになりました。詳細な説明については、Javadoc を参照してください。

すべての keycloak テーマでダークモードのサポートが有効になりました。この機能は以前は管理コンソール、アカウントコンソール、ログインに存在していましたが、ウェルカムページでも利用できるようになりました。ユーザーがオペレーティングシステム設定（例：ライトモードまたはダークモード）またはユーザーエージェント設定を通じて好みを指定すると、テーマはこれらの設定に自動的に従います。

keycloak テーマのいずれかを拡張するカスタムテーマを使用しており、ダークモードをまだサポートする準備ができていない場合、またはダークモードを実装することを妨げるスタイリングの競合がある場合は、テーマに次のプロパティを追加することでサポートを無効にできます。

または、レルム設定の テーマ タブで ダークモード 設定をオフにすることで、組み込みの Keycloak テーマのダークモードサポートをレルムごとに無効にできます。

Keycloak によって実行されたパスワード検証の回数をカウントする新しいメトリクスが利用可能です。これにより、CPU リソースがどこで使用されているかをより適切に評価し、サイジング計算に反映させることができます。

詳細については、Keycloak メトリクス および CPU およびメモリリソースのサイジングの概念 を参照してください。

以前のバージョンでは、管理コンソールで アクティブなすべてのセッションをサインアウト をクリックすると、通常のセッションのみが削除されていました。オフラインセッションは、効果的に無効になっているにもかかわらず、引き続き表示されていました。

これが変更されました。アクティブなすべてのセッションからサインアウトすると、通常のセッションとオフラインセッションの両方が削除されるようになりました。

今回のリリース以降、Keycloak JavaScript アダプターと Keycloak Node.js アダプターは、Keycloak サーバーのリリースサイクルとは独立したリリースサイクルを持つようになります。26.1.0 リリースは、これらのアダプターが Keycloak サーバーとともにリリースされる最後のリリースになる可能性がありますが、今後は、これらのアダプターは Keycloak サーバーとは異なるタイミングでリリースされる可能性があります。

Keycloak クイックスタートは、ベースブランチとして main を使用するようになりました。以前使用されていた latest ブランチは削除されました。main ブランチは、Keycloak サーバー、Keycloak クライアントライブラリ、およびアダプターの最後にリリースされたバージョンに依存します。その結果、クイックスタートへのコントリビューションは、次の Keycloak サーバーリリースを待つ必要がなく、クイックスタートの利用者にすぐに表示されます。

KEYCLOAK_SESSION クッキーの形式がわずかに更新され、プレーンテキストでプライベートデータを含まなくなりました。これまで、クッキーの形式は realmName/userId/userSessionId でした。現在、クッキーには、SHA-256 でハッシュされ、URL エンコードされたユーザーセッション ID が含まれています。

AUTH_SESSION_ID クッキーの形式が更新され、署名検証を通じて整合性を確保するために、認証セッション ID の署名が含まれるようになりました。新しい形式は base64(auth_session_id.auth_session_id_signature) です。この更新により、古い形式は受け入れられなくなり、古い認証セッションは無効になります。この変更は、ユーザーセッションには影響しません。

これらの変更は、独自のプロバイダーを実装し、Keycloak 内部クッキーの形式に依存している場合にのみ影響を与える可能性があります。

以前はデフォルトで含まれていた robots.txt ファイルが削除されました。デフォルトの robots.txt ファイルはすべてのクロールをブロックしており、noindex/nofollow ディレクティブが従われるのを防いでいました。望ましいデフォルトの動作は、Keycloak ページが検索エンジンの結果に表示されないことであり、これはデフォルトで none に設定されている既存の X-Robots-Tag ヘッダーによって実現されます。異なる動作が必要な場合は、このヘッダーの値をレルムごとにオーバーライドできます。

以前にこれのためにリバースプロキシ構成にルールを追加した場合は、削除できます。

外部で生成された鍵をインポートできる鍵プロバイダー（rsa および java-keystore ファクトリ）は、関連付けられた証明書が存在する場合、その有効性をチェックするようになりました。したがって、証明書が期限切れになっている鍵は、Keycloak にインポートできなくなりました。実行時に証明書の有効期限が切れると、鍵はパッシブ鍵（有効だがアクティブではない）に変換されます。パッシブ鍵は新しいトークンには使用されませんが、以前に発行されたトークンを検証するためには引き続き有効です。

デフォルトの generated 鍵プロバイダーは、10 年間有効な証明書を生成します（関連付けられた証明書を持つタイプまたは持つことができるタイプ）。有効期間が長く、鍵を頻繁にローテーションすることが推奨されているため、生成されたプロバイダーはこのチェックを実行しません。

今回のリリースでは、管理イベントには、イベントがトリガーされたときのコンテキストに関する追加の詳細が含まれる場合があります。アップグレードする場合は、データベーススキーマが更新され、ADMIN_EVENT_ENTITY テーブルに新しい列 DETAILS_JSON が追加されることを想定する必要があります。

OpenShift v3 はしばらく前に寿命を迎えましたが、OpenShift v3 によるアイデンティティブローカリングのサポートは Keycloak から削除されました。

Keycloak 26 以降、組織機能が完全にサポートされるようになりました。

Keycloak 25 では、機能 persistent-user-sessions が導入されました。この機能を有効にすると、オフラインセッションのみが永続化されていた以前の動作とは対照的に、すべてのユーザーセッションがデータベースに永続化されます。Keycloak 26 では、この機能はデフォルトで有効になっています。これは、すべてのユーザーセッションがデフォルトでデータベースに永続化されることを意味します。

この動作を以前の状態に戻すには、機能を無効にすることができます。詳細については、分散キャッシュの構成ガイドの「揮発性ユーザーセッション」セクションに従ってください。

アップグレード方法については、アップグレードガイドを参照してください。

keycloak ログインテーマの新しいバージョン（v2）が登場しました。これは、ユーザーの好みに基づいてダークテーマに自動的に切り替えるサポートを含め、ルックアンドフィールを向上させます。

以前のバージョン（v1）は非推奨となり、今後のリリースで削除される予定です。

すべての新しいレルムでは、keycloak.v2 がデフォルトのログインテーマになります。また、ログインテーマを明示的に設定したことのない既存のレルムは、keycloak.v2 に切り替えられます。

Keycloak 26 では、推奨される HA マルチサイトアーキテクチャに大幅な改善が加えられました。最も注目すべきは次のとおりです。

移行方法については、アップグレードガイドを参照してください。

過去には、すべての管理者ユーザーがロックアウトされた場合に Keycloak インスタンスへのアクセスを回復することは、困難で複雑なプロセスでした。これらの課題を認識し、ユーザーエクスペリエンスを大幅に向上させることを目指して、Keycloak は一時的な管理者アカウントをブートストラップし、失われた管理者アクセスを回復するためのいくつかの簡単な方法を提供するようになりました。

一時的な管理者アカウントを作成するために、特定のオプションを指定して start または start-dev コマンドを実行できるようになりました。さらに、ユーザーが手間をかけずに管理者アクセスを回復できる新しい専用コマンドが導入されました。

詳細な手順とこのトピックの詳細については、管理者ブートストラップとリカバリガイドを参照してください。

OpenTelemetry Tracing の基盤となる Quarkus サポートが Keycloak に公開され、より優れた可観測性のためにアプリケーションのトレースを取得できるようになりました。これにより、パフォーマンスのボトルネックを見つけ、アプリケーションの障害の原因を特定し、分散システムを介してリクエストをトレースするなど、多くのことができます。サポートはプレビューモードであり、フィードバックをお待ちしております。

詳細については、トレースの有効化ガイドを参照してください。

検証可能な資格情報発行のための OpenID (OID4VCI) は、Keycloak ではまだ実験的な機能ですが、今回のリリースで大幅に改善されました。Keycloak OAuth SIG では、重要な開発と議論が行われています。Keycloak コミュニティの誰もが参加することを歓迎します。

この機能の開発と議論に参加してくれた OAuth SIG グループのすべてのメンバーに感謝します。特に、Francis Pouatcha氏、Pascal Knüppel氏、Takashi Norimatsu氏、Ingrid Kamga氏、Stefan Wiedemann氏、Thomas Darimont氏に感謝します。

DPoP（OAuth 2.0 Demonstrating Proof-of-Possession）プレビュー機能が改善されました。DPoP はすべてのグラントタイプでサポートされるようになりました。以前のリリースでは、この機能は authorization_code グラントタイプでのみサポートされていました。UserInfo エンドポイントでの DPoP トークンタイプのサポートも存在します。

貢献してくれたPascal Knüppel氏に感謝します。

GELF サポートはしばらくの間非推奨とされていましたが、今回のリリースで Keycloak から完全に削除されました。他のログハンドラーは利用可能であり、GELF の代替として使用するために完全にサポートされています。たとえば、Syslog などがあります。詳細については、ロギングガイドを参照してください。

軽量アクセストークンを Admin REST API で使用できるようになりました。security-admin-console および admin-cli クライアントは、デフォルトで軽量アクセストークンを使用するようになり、「常に軽量アクセストークンを使用する」および「フルスコープを許可する」がこれら 2 つのクライアントで有効になりました。ただし、管理コンソールでの動作は事実上同じままです。これら 2 つのクライアントに変更を加えた場合や、他の目的で使用している場合は注意してください。

Keycloak JavaScript アダプターはスタンドアロンライブラリになり、Keycloak サーバーから静的に提供されなくなりました。目標は、ライブラリを Keycloak サーバーから分離し、独立してリファクタリングできるようにすることで、コードを簡素化し、将来のメンテナンスを容易にすることです。さらに、ライブラリはサードパーティの依存関係から解放され、軽量化され、さまざまな環境で使いやすくなりました。

変更点の完全な内訳については、アップグレードガイドを参照してください。

非推奨のホスト名 v1 機能が削除されました。この機能は Keycloak 25 で非推奨となり、ホスト名 v2 に置き換えられました。この機能をまだ使用している場合は、ホスト名 v2 に移行する必要があります。詳細については、ホスト名（v2）の構成 および 最初の移行ガイド を参照してください。

http-relative-path プロパティが指定されている場合、ユーザーは Keycloak がホストされているパスに自動的にリダイレクトされます。つまり、相対パスが /auth に設定されており、ユーザーが localhost:8080/ にアクセスすると、ページは localhost:8080/auth にリダイレクトされます。

http-management-relative-path または http-relative-path プロパティが指定されている場合、管理インターフェースにも同じことが当てはまります。

ユーザーエクスペリエンスが向上し、ユーザーは URL に相対パスを明示的に設定する必要がなくなりました。

今回のリリースでは、組み込みキャッシュを使用している場合、デフォルトでクラスターが再起動されると、失効したアクセストークンがデータベースに書き込まれ、再ロードされます。

移行方法については、アップグレードガイドを参照してください。

クライアントポリシーにクライアント属性に基づく条件が追加されました。条件を使用して、指定されたクライアント属性を持つクライアントを指定された値に指定できます。クライアントポリシーのドキュメントで説明されているように、この条件を評価するときに AND または OR 条件のいずれかを使用できます。

貢献してくれたYoshiyuki Tabata氏に感謝します。

console、file、syslog など、利用可能なすべてのログハンドラーにログレベルを指定できます。よりきめ細かいアプローチにより、アプリケーション全体のロギングを制御し、ニーズに合わせて調整する機能が提供されます。

詳細については、ロギングガイドを参照してください。

非推奨の proxy オプションが削除されました。このオプションは Keycloak 24 で非推奨となり、必要に応じてホスト名オプションと組み合わせて proxy-headers オプションに置き換えられました。詳細については、リバースプロキシの使用 および 最初の移行ガイド を参照してください。

proxy-trusted-addresses は、proxy-headers オプションが設定されている場合に、信頼できるプロキシアドレスの許可リストを指定するために使用できます。特定のリクエストのプロキシアドレスが信頼されていない場合、それぞれのプロキシヘッダー値は使用されません。

proxy-protocol-enabled オプションは、プロキシの背後からリクエストを処理するときに、サーバーが HA PROXY プロトコルを使用するかどうかを制御します。true に設定すると、返されるリモートアドレスは、実際の接続クライアントからのアドレスになります。

https-certificates-reload-period オプションを設定して、https-* オプションで参照されるキーストア、トラストストア、および証明書ファイルのリロード期間を定義できます。リロードを無効にするには -1 を使用します。デフォルトは 1 時間（1h）です。

--cache-embedded-${CACHE_NAME}-max-count= を設定して、指定されたキャッシュ内のキャッシュエントリ数の上限を定義できます。

コミュニティからのフィードバックに基づいて、信頼できる証明書の粒度を向上させるために、https-trust-store-* オプションの非推奨を解除することにしました。

外部の Java キーストアファイルからレルムキーをロードできる java-keystore キープロバイダーが変更され、すべての Keycloak アルゴリズムを管理できるようになりました。さらに、ストアから実際のキーを取得するために必要なキーストアとキーのシークレットは、Vault を使用して設定できます。これにより、Keycloak レルムは、機密データをデータベースに保存せずに、任意のキーを暗号化されたファイルに外部化できます。

この件に関する詳細については、レルムキーの設定 を参照してください。

Keycloak で、クライアントの暗号化キー管理アルゴリズムとして ECDH-ES、ECDH-ES+A128KW、ECDH-ES+A192KW、または ECDH-ES+A256KW を設定できるようになりました。Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) による鍵共有の仕様では、JWT 用に 3 つの新しいヘッダーパラメーター (epk、apu、および apv) が導入されています。現在、Keycloak の実装では必須の epk のみを管理しており、他の 2 つ (オプション) はヘッダーに追加されることはありません。これらのアルゴリズムの詳細については、JSON Web Algorithms (JWA) を参照してください。

また、新しいキープロバイダーである ecdh-generated がレルムキーを生成するために利用可能になり、Java KeyStore プロバイダーに ECDH アルゴリズムのサポートが追加されました。

貢献してくれた Justin Tay に感謝します。

レルム内で同じソーシャルブローカーの複数のインスタンスを持つことが可能になりました。

ほとんどの場合、レルムは同じソーシャルブローカーの複数のインスタンスを必要としません。しかし、organization 機能の導入により、同じソーシャルブローカーの異なるインスタンスを異なる組織にリンクすることが可能になるはずです。

ソーシャルブローカーを作成するときは、他のブローカーと同様に、Alias とオプションで Display name を指定する必要があります。

認証情報の更新 (UPDATE_CREDENTIAL) および削除 (REMOVE_CREDENTIAL) 用の汎用イベントが追加されました。イベントの credential_type 属性で認証情報のタイプが記述されています。新しいイベントタイプは、Email Event Listener でサポートされています。

以下のイベントタイプは非推奨となり、将来のバージョンで削除される予定です: UPDATE_PASSWORD、UPDATE_PASSWORD_ERROR、UPDATE_TOTP、UPDATE_TOTP_ERROR、REMOVE_TOTP、REMOVE_TOTP_ERROR

base/login および keycloak.v2/login テーマの template.ftl ファイルで、ログインボックスのフッターをカスタマイズできるようになりました。これは、共通リンクを表示したり、ページ末尾にカスタムスクリプトを含めたりするために使用できます。

新しい footer.ftl テンプレートは、"ログインボックス" の下部にレンダリングされる content マクロを提供します。

Keycloak CR が、Keycloak Pod のスケジューリングを制御するためのファーストクラスプロパティを公開するようになりました。

詳細については、Operator Advanced Configuration を参照してください。

KeycloakRealmImport CR が、インポート時にプレースホルダーの置換を行うための環境変数を作成するために spec.placeholders を公開するようになりました。

詳細については、Operator Realm Import を参照してください。

今回のリリースでは、LDAP 接続プールの設定はシステムプロパティのみに依存します。

詳細については、接続プールの設定 を参照してください。

マーシャリングは、Java オブジェクトをバイトに変換して、Keycloak サーバー間でネットワーク経由で送信するプロセスです。Keycloak 26 では、マーシャリング形式を JBoss Marshalling から Infinispan Protostream に変更しました。

Infinispan Protostream は Protocol Buffers (proto 3) に基づいており、下位/上位互換性があるという利点があります。

OSGi メタデータを使用していた Java アダプターがすべて削除されたため、jar 用の OSGi メタデータの生成を停止しました。

グループのスケーラビリティを向上させる目的で、レルムを削除する際にグループがデータベースから直接削除されるようになりました。その結果、レルムの削除時に GroupRemovedEvent のようなグループ関連のイベントが発火しなくなりました。

移行方法については、アップグレードガイドを参照してください。

多くの ID プロバイダーを持つレルムと組織のスケーラビリティに関する改善の一環として、レルム表現は ID プロバイダーのリストを保持しなくなりました。ただし、レルムをエクスポートするときは、レルム表現から引き続き利用可能です。

移行方法については、アップグレードガイドを参照してください。

Securing Applications and Services ドキュメントが、以前のリリースで変換された Server Installation and Configuration ドキュメントと同様の新しい形式に変換されました。ドキュメントは Keycloak Guides で利用できるようになりました。

Keycloak は、古いブラウザーがクッキーの SameSite フラグをサポートしていないことへの回避策として導入された _LEGACY クッキーを送信しなくなりました。

_LEGACY クッキーは、安全でないコンテキストからのログインを許可するという別の目的も果たしていました。これは Keycloak の本番環境へのデプロイではまったく推奨されませんが、localhost 外の http 経由で Keycloak にアクセスすることはかなり頻繁にあります。_LEGACY クッキーの代替として、Keycloak は安全でないコンテキストが使用されていることを検出すると、secure フラグを設定せず、SameSite=None の代わりに SameSite=Lax を設定するようになりました。

UserRepresentation の origin プロパティは非推奨となり、将来のリリースで削除される予定です。

代わりに、ユーザーがリンクされているプロバイダーを取得するには、federationLink プロパティを使用することを推奨します。

アカウントコンソール v2 テーマが Keycloak から削除されました。このテーマは Keycloak 24 で非推奨となり、アカウントコンソール v3 テーマに置き換えられました。まだこのテーマを使用している場合は、アカウントコンソール v3 テーマに移行する必要があります。

Keycloak は最新の LTS OpenJDK バージョンに準拠するため、OpenJDK 21 をサポートするようになりました。

OpenJDK 17 のサポートは Keycloak で非推奨となり、OpenJDK 21 を優先して、今後のリリースで削除される予定です。

以前の Keycloak バージョンのリリースノートで述べたように、ほとんどの Java アダプターが Keycloak コードベースおよびダウンロードページから削除されました。

OAuth 2.0/OIDC については、Tomcat アダプター、WildFly/EAP アダプター、Servlet Filter アダプター、KeycloakInstalled デスクトップアダプター、jaxrs-oauth-client アダプター、JAAS ログインモジュール、Spring アダプター、および SpringBoot アダプターの削除が含まれます。いくつかの代替案のリストについては、以前の投稿 を確認できます。

SAML については、Tomcat アダプターと Servlet フィルターアダプターの削除が含まれます。SAML アダプターは、WildFly および JBoss EAP で引き続きサポートされています。

汎用 Authorization Client ライブラリは引き続きサポートされており、今後もサポートする予定です。これは、他の OAuth 2.0 または OpenID Connect ライブラリと組み合わせて使用​​することを目的としています。この認可クライアントライブラリが Elytron OIDC や SpringBoot などのサードパーティ Java アダプターとともに使用されている例については、quickstarts を確認できます。WildFly で使用されている SAML アダプターの例についても、quickstarts を確認できます。

Keycloak 24 では、ウェルカムページが PatternFly 5、Keycloak のユーザーインターフェイスを支えるデザインシステムの最新バージョンを使用するように更新されました。今回のリリースでは、管理コンソールとアカウントコンソールも PatternFly 5 を使用するように更新されました。管理コンソールとアカウントコンソールを拡張およびカスタマイズする場合は、PatternFly 5 の変更点 を確認し、カスタマイズを適宜更新してください。

Argon2 は、FIPS 環境以外で Keycloak が使用するデフォルトのパスワードハッシュアルゴリズムになりました。

Argon2 は 2015 年のパスワードハッシュコンペティション の優勝者であり、OWASP によって推奨されているハッシュアルゴリズムです。

Keycloak 24 では、PBKDF2 のデフォルトのハッシュ反復回数が 27.5K から 210K に増加し、パスワードハッシュの生成に必要な CPU 時間が 10 倍以上増加しました。Argon2 を使用すると、以前のバージョンの Keycloak とほぼ同じ CPU 時間で、より優れたセキュリティを実現できます。1 つの欠点は、Argon2 が GPU 攻撃に対する耐性を備えるために、より多くのメモリを必要とすることです。Keycloak の Argon2 のデフォルトでは、ハッシュリクエストごとに 7MB が必要です。過剰なメモリと CPU 使用率を防ぐため、Argon2 によるハッシュの並列計算は、デフォルトで JVM で利用可能なコア数に制限されています。Argon2 のメモリ集中型の性質をサポートするために、デフォルトの GC を ParallelGC から G1GC に更新して、ヒープの使用率を向上させました。

Argon2 は FIPS 140-2 に準拠していないことに注意してください。したがって、FIPS 環境にいる場合、デフォルトのアルゴリズムは引き続き PBKDF2 になります。また、FIPS 環境以外にいて、FIPS 環境に移行することを計画している場合は、パスワードポリシーを pbkdf2-sha512 などの FIPS 準拠のアルゴリズムに変更することを早めに検討してください。そうしないと、FIPS 環境に切り替えた後、ユーザーはログインできなくなります。

以前のホスト名設定の複雑さと直感性の欠如に対応して、Hostname v2 オプションを導入できることを誇りに思います。

皆様からのフィードバックに耳を傾け、厄介な問題に取り組み、ホスト名設定を管理するためのよりスムーズなエクスペリエンスを作成しました。これらのオプションの背後にある動作も変更されており、カスタムホスト名設定を扱っている場合は注意が必要です。

古いホスト名オプションは非推奨となり、今後のリリースで削除されるため、Hostname v2 オプションはデフォルトでサポートされています。できるだけ早く移行する必要があります。

新しいオプションはデフォルトで有効になっているため、Keycloak は古いオプションを認識しません。

移行方法については、アップグレードガイドを参照してください。

以前のバージョンの Keycloak では、オフラインユーザーセッションとオフラインクライアントセッションのみがデータベースに保存されていました。新しい機能である persistent-user-sessions は、オンラインユーザーセッションとオンラインクライアントセッションをメモリだけでなくデータベースにも保存します。これにより、Keycloak のすべてのインスタンスが再起動またはアップグレードされた場合でも、ユーザーはログイン状態を維持できます。

この機能はプレビュー機能であり、デフォルトでは無効になっています。使用するには、ビルドコマンドに以下を追加します。

詳細については、機能の有効化と無効化 ガイドを参照してください。サイジングガイド には、この機能が有効になっている場合の更新されたリソース要件について説明する新しい段落が含まれています。

アップグレード方法については、アップグレードガイドを参照してください。

カスタムクッキーを設定するための次の API が削除されました。

Keycloak 23 リリースでは、ユーザーが複数のブラウザータブで並行して認証された場合の改善が提供されました。ただし、この改善は認証セッションが期限切れになった場合には対応していませんでした。ユーザーが 1 つのブラウザータブですでにログインしており、他のブラウザータブで認証セッションが期限切れになった場合、Keycloak は OIDC/SAML エラーでクライアントアプリケーションにリダイレクトバックできるようになりました。これにより、クライアントアプリケーションは認証をすぐに再試行できます。通常、SSO セッションのためにアプリケーションに自動的にログインする必要があります。詳細については、サーバー管理ガイドの認証セッション を参照してください。

以前のリリースでは、軽量アクセストークンのサポートが追加されました。今回のリリースでは、軽量アクセストークンからさらに多くの組み込みクレームを削除することに成功しました。クレームはプロトコルマッパーによって追加されます。それらの一部は、OIDC 仕様で厳密に要求されていなかったため、通常のアクセストークンまたは ID トークンにも影響を与えます。

詳細については、アップグレードガイド を参照してください。

トークンイントロスペクションエンドポイントを呼び出すときに、HTTP ヘッダー Accept: application/jwt を使用できます。特定のクライアントで有効にすると、トークンイントロスペクションエンドポイントからクレーム jwt が、完全な JWT アクセストークンとともに返されます。これは、イントロスペクションエンドポイントを呼び出すクライアントが軽量アクセストークンを使用した場合に特に役立ちます。貢献してくれた Thomas Darimont に感謝します。

Keycloak は、ユーザー名を含むユーザーパスワードを拒否できる新しいパスワードポリシーをサポートしています。

管理コンソールで、特定のレルムの [必須アクション] タブでいくつかの必須アクションを設定できるようになりました。現在、[パスワードの更新] が唯一の組み込みの構成可能な必須アクションです。これは、再認証なしで kc_action パラメーター (アカウントコンソールでパスワードを更新するときなどに使用) によってユーザーがパスワードを更新できる最大時間である 認証の最大経過時間 の設定をサポートしています。必須アクションのソートも改善されました。認証中に複数の必須アクションがある場合、認証中に設定されたアクション (たとえば、kc_action パラメーターによるアクション) であろうと、管理者によってユーザーアカウントに手動で追加されたアクションであろうと、すべてのアクションがまとめてソートされます。貢献してくれた Thomas Darimont と Daniel Fesenmeyer に感謝します。

パスキーの条件付き UI のサポートが追加されました。パスキープレビュー機能が有効になっている場合、専用の認証器が利用可能になります。つまり、利用可能なパスキーアカウントのリストから選択し、それに基づいてユーザーを認証できます。貢献してくれた Takashi Norimatsu に感謝します。

セキュアな SAML クライアントを持つためのデフォルトクライアントプロファイルが追加されました。管理コンソールでレルムのクライアントポリシーを閲覧すると、新しいクライアントプロファイル saml-security-profile が表示されます。これを使用すると、署名が強制され、SAML リダイレクトバインディングが無効になり、ワイルドカードリダイレクト URL が禁止されるなど、SAML クライアントにセキュリティのベストプラクティスが適用されます。

新しい認証器 Confirm override existing link が追加されました。この認証器を使用すると、以前に別の IDP アイデンティティにリンクされていた Keycloak ユーザーのリンクされた IDP ユーザー名をオーバーライドできます。詳細については、サーバー管理ガイド を参照してください。貢献してくれた Lex Cao に感謝します。

検証可能な資格情報発行のための OpenID (OID4VCI) のサポートが進行中です。現時点では、これはまだ進行中の作業ですが、徐々に機能が追加されています。Keycloak は、事前承認コードフローのサポートにより、OID4VC 発行者として機能できます。JWT-VC、SD-JWT-VC、および VCDM 形式の検証可能な資格情報のサポートがあります。貢献とフィードバックをくれた OAuth SIG グループのメンバー、特に Stefan Wiedemann、Francis Pouatcha、Takashi Norimatsu、および Yutaka Obuchi に感謝します。

ユーザー属性でユーザーを検索する場合、Keycloak はユーザー属性名を検索する際に小文字比較を強制しなくなりました。この変更の目的は、ユーザー属性テーブルの Keycloak ネイティブインデックスを使用して検索を高速化することでした。データベースの照合順序で大文字と小文字が区別されない場合、検索結果は以前と同じになります。データベースの照合順序で大文字と小文字が区別される場合、以前よりも検索結果が少なくなる可能性があります。

keycloak-authz-client ライブラリのユーザーの場合、AuthorizationResource.getPermissions(…​) を呼び出すと、List<Permission> が正しく返されるようになりました。

以前は、メソッド宣言で List<Permission> がアドバタイズされていたにもかかわらず、ランタイム時に List<Map> が返されていました。

この修正により、List またはそのコンテンツを List<Map> にキャストすることに依存していたコードが壊れます。このメソッドを何らかの形で使用したことがある場合は、これを行った可能性が高く、影響を受ける可能性があります。

クライアントの認可設定をエクスポートするときに、リソース、スコープ、およびポリシーの ID が設定されなくなりました。その結果、あるクライアントから別のクライアントに設定をインポートできるようになりました。

メトリクスとヘルスチェックエンドポイントは、標準の Keycloak サーバーポートからはアクセスできなくなりました。これらのエンドポイントは外部に公開されるべきではないため、別のデフォルト管理ポート 9000 でアクセスできます。

これにより、Kubernetes 環境の標準 Keycloak エンドポイントとしてユーザーに公開しないことが可能になります。新しい管理インターフェイスは、新しいオプションセットを提供し、完全に構成可能です。

Keycloak Operator は、管理インターフェイスがデフォルトでオンになっていることを前提としています。詳細については、管理インターフェイスの設定 を参照してください。

Keycloak は、リモートロギング用の Syslog プロトコルをサポートするようになりました。RFC 5424 で定義されたプロトコルを利用しています。デフォルトでは、syslog ハンドラーは無効になっていますが、有効にすると、すべてのログイベントをリモート syslog サーバーに送信します。

詳細については、ロギングの設定 ガイドを参照してください。

メソッド EnvironmentDependentProviderFactory.isSupported() は、いくつかのリリースで非推奨となり、削除されました。

詳細については、アップグレードガイド を参照してください。

cache、cache-stack、および cache-config-file オプションをランタイム時に指定できるようになりました。これにより、ビルドフェーズを実行したり、イメージを再構築したりする必要がなくなりました。

詳細については、アップグレードガイド を参照してください。

高可用性ガイドに、バックアップサイトからプライマリサイトへの意図しない自動フェイルバックを防ぐために AWS Lambda を構成する方法に関するガイドが含まれるようになりました。

今回のリリースでは、次のクラスから非推奨のメソッドを最終的に削除します。

詳細については、アップグレードガイド を参照してください。

AccessToken、IDToken、および JsonWebToken から非推奨のメソッドが削除された結果、SingleUseObjectKeyModel も、有効期限値に関連するメソッド名を一貫させるために変更されました。

詳細については、アップグレードガイド を参照してください。

サポートおよびテスト済みのデータベースに PostgreSQL 16 が含まれるようになりました。

今回のリリースでは、Keycloak Organizations をテクノロジープレビュー機能として提供します。

この機能は、より多くの機能を将来提供するためのベースラインとなる、コア CIAM 機能を備えたレルムを提供し、企業間 (B2B) および企業間対企業間顧客 (B2B2C) のユースケースに対応します。

機能の面では、この機能は完成しています。ただし、次のメジャーリリースで完全にサポートするためには、まだ作業が必要です。残りの作業は主に、スケーラビリティに焦点を当てて、本番環境へのデプロイに向けて機能を準備することです。また、次のメジャーリリースまでに得られるフィードバックによっては、ロードマップを損なうことなく、追加の機能を受け入れ、機能にさらに価値を追加する可能性があります。

詳細については、サーバー管理ガイド を参照してください。

今回のリリースには、PAR (Pushed Authorization Request) を使用する一部の OIDC コンフィデンシャルクライアントに影響を与える重要なセキュリティ問題の修正が含まれています。OIDC コンフィデンシャルクライアントを PAR とともに使用し、HTTP リクエストボディのパラメーターとして送信される client_id と client_secret に基づくクライアント認証 (OIDC 仕様で指定されたメソッド client_secret_post) を使用する場合は、このバージョンにアップグレードした後、クライアントのクライアントシークレットをローテーションすることを強くお勧めします。

Admin User API を介してユーザー属性を更新する場合、username、email、firstName、および lastName などのルート属性を含め、ユーザー属性を更新するときに部分的な更新を実行することはできません。

詳細については、アップグレードガイド を参照してください。

Operator を使用して Keycloak をデプロイするとき、リリースプロセスに問題が発生したため、24.0.0 の代わりに nightly コンテナーがインストールされました。

この問題の迅速な修正として、24.0.0 コンテナーに nightly というタグが付けられ、nightly リリースは一時的に無効になりました。

昨日 CET 午後 5 時より前に Operator を使用して 24.0.0 をインストールまたはアップグレードした場合、データベースが間違ったバージョンで更新されている可能性があります。影響を受けているかどうかを確認するには、データベースに接続して、次の SQL コマンドを実行してください。

上記で一致する行が返された場合は、何らかのアクションを実行する必要があります。そうしないと、今後のリリースでデータベース移行が実行されません。これを解決するには、次の SQL コマンドを実行してください。

ユーザープロファイルプレビュー機能が完全にサポートされるようになり、ユーザープロファイルがデフォルトで有効になりました。

過去数か月間、Keycloak チームはユーザープロファイル機能を完全にサポートするために多大な努力を費やしてきました。今回のリリースでは、その取り組みを継続しました。徹底的なテストと素晴らしいコミュニティからのフィードバックに基づいて、多くの改善、修正、および調整が行われました。

以下は、この機能のいくつかのハイライトです。

サポートされる機能としてのユーザープロファイルの最初のリリースは、出発点に過ぎず、アイデンティティ管理に関するさらに多くの機能を提供するためのベースラインです。

多くのアイデア、要件、および貢献がコミュニティから寄せられたため、素晴らしい Keycloak コミュニティに心から感謝申し上げます。特に感謝を申し上げたいのは、

ユーザープロファイル機能の詳細については、サーバー管理ガイド を参照してください。

2022 年に、Keycloak 19 での Keycloak アダプターの非推奨 を発表しました。コミュニティがこれに適応するための時間を増やすために、が延期されました。

それを念頭に置いて、これは OpenID Connect および SAML アダプターを含む Keycloak の最後のメジャーリリースになります。Jetty 9.x は 2022 年からサポートされていないため、Jetty アダプターは今回のリリースで既に削除されています。

汎用 Authorization Client ライブラリは引き続きサポートされ、他の OAuth 2.0 または OpenID Connect ライブラリと組み合わせて使用​​することを目的としています。

継続して提供する唯一のアダプターは、WildFlyおよびEAP 8.x の最新リリース用の SAML アダプターです。これをサポートし続ける理由は、Keycloak の SAML コードベースの大部分が WildFly からの貢献であるという事実にあります。この貢献の一環として、WildFly および EAP 用の SAML アダプターを長期的にメンテナンスすることに合意しました。

Keycloak を初めて使用する際に表示される「ウェルカム」ページが再設計されました。これにより、セットアップエクスペリエンスが向上し、最新バージョンの PatternFly に準拠するようになりました。簡素化されたページレイアウトには、最初の管理者ユーザーを登録するためのフォームのみが含まれています。登録が完了すると、ユーザーは直接管理コンソールに移動します。

カスタムテーマを使用している場合は、新しいウェルカムページをサポートするためにテーマを更新する必要がある場合があります。詳細については、アップグレードガイドを参照してください。

Keycloak 22 でアカウントコンソールバージョン 3 をプレビュー機能として導入しました。このリリースでは、これをデフォルトバージョンとし、バージョン 2 を非推奨とします。バージョン 2 は今後のリリースで削除される予定です。

この新しいバージョンには、ユーザープロファイル機能の組み込みサポートが含まれており、管理者アカウントコンソールでユーザーが利用できる属性を設定できます。また、ログイン後、ユーザーを自分の個人アカウントページに直接誘導します。

このテーマのカスタマイズ機能を使用または拡張している場合は、追加の移行が必要になる場合があります。詳細については、アップグレードガイドを参照してください。

このリリースでは、パスワードハッシュのデフォルトを OWASP のパスワードストレージに関する推奨事項 に合わせました。

この変更の一環として、デフォルトのパスワードハッシュプロバイダーが pbkdf2-sha256 から pbkdf2-sha512 に変更されました。また、pbkdf2 ベースのパスワードハッシュアルゴリズムのデフォルトのハッシュ反復回数も変更されました。この変更は、最新の推奨事項に沿ったセキュリティの向上を意味しますが、パフォーマンスに影響があります。レルムにパスワードポリシー hashAlgorithm と hashIterations を追加することで、以前の動作を維持することが可能です。詳細については、アップグレードガイドを参照してください。

CORS 関連の Keycloak 機能が SPI に抽出され、これにより柔軟性が向上する可能性があります。CorsSPI は内部であり、今後のリリースで変更される可能性があることに注意してください。貢献してくれた Dmitry Telegin 氏に感謝します。

Keycloak は、トラストストアの構成オプションを改善しました。Keycloak トラストストアは、送信接続、mTLS、データベースドライバーなど、サーバー全体で使用されるようになりました。個々の領域に個別のトラストストアを構成する必要はなくなりました。トラストストアを構成するには、トラストストアファイルまたは証明書をデフォルトの conf/truststores に配置するか、新しい truststore-paths 構成オプションを使用できます。詳細については、関連する ガイド を参照してください。

機能がバージョン管理をサポートするようになりました。下位互換性を維持するために、既存のすべての機能 (account2 や account3 を含む) はバージョン 1 としてマークされています。新しく導入された機能はバージョン管理を使用します。つまり、ユーザーは目的の機能のさまざまな実装から選択できます。

詳細については、機能ガイド を参照してください。

SAML アイデンティティプロバイダーは、IDP エンティティメタデータ記述子エンドポイントから署名証明書を自動的にダウンロードするように構成できるようになりました。新しい機能を使用するには、プロバイダーで [メタデータ記述子 URL] オプション (証明書を含む IDP メタデータ情報が公開されている URL) を構成し、[メタデータ記述子 URL を使用] を [ON] に設定します。証明書は、その URL から自動的にダウンロードされ、public-key-storage SPI にキャッシュされます。証明書は、プロバイダーページの [アクション] コンボを使用して、管理コンソールからリロードまたはインポートすることもできます。

新しいオプションの詳細については、ドキュメント を参照してください。

/lb-check で利用可能な新しいヘルスチェックエンドポイントが追加されました。実行はイベントループで実行されます。つまり、このチェックは、Keycloak がリクエストキューで待機している多くのリクエストを処理する必要がある過負荷状態でも応答性があります。この動作は、たとえば、負荷が高い別のサイトへのフェイルオーバーを回避するために、マルチサイトデプロイメントで役立ちます。エンドポイントは現在、組み込みおよび外部の Infinispan キャッシュの可用性をチェックしています。他のチェックは後で追加される可能性があります。

このエンドポイントはデフォルトでは利用できません。有効にするには、multi-site 機能を指定して Keycloak を実行します。詳細については、機能の有効化と無効化 を参照してください。

Keycloak CR に startOptimized フィールドが含まれるようになり、これにより、開始コマンドに --optimized フラグを使用するかどうかに関するデフォルトの想定をオーバーライドできます。その結果、カスタム Keycloak イメージが使用されている場合でも、CR を使用してビルド時のオプションを構成できます。

新しい --proxy-headers オプションを使用することで、Forwarded または X-Forwarded-* ヘッダーのいずれかの解析を個別に有効にできるようになりました。詳細については、リバースプロキシガイド を参照してください。元の --proxy オプションは非推奨となり、今後のリリースで削除される予定です。移行手順については、アップグレードガイド を参照してください。

このリリースでは、ルートユーザー属性 (username、email、firstName、lastName、locale など) を、管理者とアカウント REST API の両方を使用する場合にこれらの属性がどのようにマーシャルおよびアンマーシャルされるかを調整するために、基本/抽象クラスに移動してカプセル化しています。

この戦略は、クライアントが属性を管理する方法の一貫性を提供し、レルムに設定されたユーザープロファイル構成に準拠していることを保証します。

詳細については、アップグレードガイド を参照してください。

このリリースから、Keycloak クラスターの最初のメンバーは、リモートセッションを並行ではなく順次ロードします。オフラインセッションのプリロードが有効になっている場合は、それらも順次ロードされます。

詳細については、アップグレードガイド を参照してください。

このリリースでは、ユーザーがすでに認証されており、アクションが別のユーザーにバインドされている場合、メール検証などのアクションを実行できなくなりました。たとえば、ユーザーはメールリンクが別のアカウントにバインドされている場合、検証メールフローを完了できません。

このリリースでは、ユーザーがメールを検証するためのリンクをたどろうとして、メールが以前に検証されている場合、適切なメッセージが表示されます。

それに加えて、新しいエラー (EMAIL_ALREADY_VERIFIED) イベントが、すでに検証済みのメールを検証しようとした試行を示すために発生します。このイベントを使用して、リンクが漏洩した場合のユーザーアカウントのハイジャックの可能性を追跡したり、ユーザーがアクションを認識しない場合にユーザーに警告したりできます。

Keycloak のデフォルトの動作は、オンデマンドでオフラインセッションをロードすることです。起動時にプリロードする古い動作は非推奨になりました。これは、起動時にプリロードすると、セッション数の増加に対応して適切にスケールせず、Keycloak のメモリ使用量が増加するためです。古い動作は今後のリリースで削除される予定です。

詳細については、アップグレードガイド を参照してください。

メモリ要件を削減するために、Infinispan キャッシュにインポートされたオフラインセッションの寿命を短縮するための構成オプションを導入しました。現在、オフラインセッションの寿命オーバーライドはデフォルトで無効になっています。

詳細については、サーバー管理ガイド を参照してください。

Keycloak の組み込みキャッシュのメトリクスを有効にすると、メトリクスはキャッシュマネージャーとキャッシュ名にラベルを使用するようになりました。

詳細については、アップグレードガイド を参照してください。

このリリース以降、Keycloak は、以前は制限されていた 255 文字を超えるユーザー属性値の保存と検索をサポートします。

詳細については、アップグレードガイド を参照してください。

ブルートフォース保護にいくつかの機能強化が加えられました。

以前のバージョンの Keycloak では、ユーザー、グループ、またはクライアントポリシーの最後のメンバーが削除されると、そのポリシーも削除されていました。残念ながら、ポリシーが集約ポリシーで使用されている場合、これは権限のエスカレーションにつながる可能性がありました。権限のエスカレーションを回避するために、エフェクトポリシーは削除されなくなり、管理者はそれらのポリシーを更新する必要があります。

Keycloak CR では、cache スペックの configMapFile フィールドを使用して、cache-config-file オプションを指定できるようになりました。例：

Keycloak CR では、Keycloak コンテナーのコンピューティングリソースを管理するための resources オプションを指定できるようになりました。Keycloak CR を介してメインの Keycloak デプロイメントのリソースを個別に要求および制限し、Realm Import CR を介してレルムインポートジョブのリソースを個別に要求および制限する機能を提供します。

値が指定されていない場合、デフォルトの requests メモリは 1700MiB に設定され、limits メモリは 2GiB に設定されます。

要件に基づいてカスタム値を指定できます。例：

詳細については、Operator の高度な構成 を参照してください。

ブルートフォースプロテクターによってユーザーが一時的にロックアウトされた場合に、新しいイベント USER_DISABLED_BY_TEMPORARY_LOCKOUT が発生するようになりました。新しいイベントが構造化された形式で情報を提供するため、ID KC-SERVICES0053 のログは削除されました。

詳細については、アップグレードガイド を参照してください。

Cookie 処理コードがリファクタリングおよび改善され、新しい Cookie プロバイダーが含まれています。これにより、Keycloak によって処理される Cookie の一貫性が向上し、必要に応じて Cookie に関する構成オプションを導入する機能が提供されます。

NameID のユーザー属性マッパーでは、[Name ID 形式] オプションを次の値に設定できました。

ただし、Keycloak はこれらの NameIDPolicy のいずれかを含む AuthnRequest ドキュメントの受信をサポートしていないため、これらのマッパーが使用されることはありませんでした。サポートされているオプションは、次の Name ID 形式のみを含むように更新されました。

Keycloak は、初期ヒープサイズと最大ヒープサイズにハードコードされた値を指定する代わりに、コンテナの総メモリに対する相対値を使用します。JVM オプション -Xms と -Xmx は、-XX:InitialRAMPercentage と -XX:MaxRAMPercentage に置き換えられました。

詳細については、アップグレードガイド を参照してください。

GELF との統合を提供する 基盤となるライブラリ のサポート終了に伴い、Keycloak は GELF ログハンドラーをすぐにサポートしなくなります。この機能は今後のリリースで削除される予定です。外部ログ管理が必要な場合は、ファイルログ解析の使用を検討してください。

複数の独立したサイトに Keycloak をデプロイすることは、高可用性と障害からの迅速な復旧を提供するために、一部の環境では不可欠です。このリリースでは、Keycloak のアクティブ/パッシブデプロイメントをサポートしています。

開始するには、クラウド環境に高可用性 Keycloak をデプロイするための包括的なブループリントも含まれている 高可用性ガイド を使用してください。

宣言型ユーザープロファイルは、このリリースでもプレビュー機能ですが、サポートされている機能に昇格させるために懸命に取り組んでいます。フィードバックをお待ちしております。問題が見つかった場合や改善案がある場合は、Github issue を作成してください。理想的には area/user-profile ラベルを付けてください。このリリースの移行変更に関する追加情報については、アップグレードガイド を確認することもお勧めします。

多数のグループとサブグループを使用するユースケースで、グループの検索に関するパフォーマンスが向上しました。サブグループのページネーションルックアップを可能にする改善があります。貢献してくれた Alice 氏に感謝します。

セキュリティ脆弱性が Keycloak 22.0.2 で導入されました。22.0.2 へのアップグレードは強くお勧めしません。また、22.0.2 を本番環境にデプロイした場合は、すぐに 22.0.3 にアップグレードしてください。

Keycloak が 22.0.2 にアップグレードされた後に自己登録したユーザーの場合、パスワードは安全に保存されておらず、Keycloak の管理者に公開される可能性があります。これは、アップグレードがロールアウトされた後に登録したユーザーにのみ影響し、以前に登録したユーザーには影響しません。

プレビュー宣言型ユーザープロファイルを使用しているレルムは、この問題の影響を受けず、デフォルトのユーザープロファイルプロバイダーを使用しているレルムのみが影響を受けます。

デプロイメントに影響を受けるユーザーがいるかどうかを特定するには、データベースにアクセスし、次の SQL ステートメントを実行してクエリできます。

影響を受けるユーザーに連絡し、パスワード更新必須アクションを追加することをお勧めします。

影響を受けるユーザーがいる場合は、次の SQL ステートメントを実行して、これらの属性をデータベースから削除することもお勧めします。

22.0.2 リリース以降にデータベースのバックアップが実行され、影響を受けるユーザーがいる場合は、これらを削除することをお勧めします。

Keycloak は、レルム内の複数の LDAP プロバイダーをサポートするようになり、同じ Kerberos レルムとの Kerberos 統合をサポートします。LDAP プロバイダーが Kerberos/SPNEGO を介して認証されたユーザーを見つけることができない場合、Keycloak は次の LDAP プロバイダーへのフォールバックを試みます。Keycloak は、単一の LDAP プロバイダーが相互に信頼関係にある複数の Kerberos レルムをサポートする場合にも、より優れたサポートを提供します。

OpenShift 3.x の内部 IdP を Keycloak に置き換えることを可能にした openshift-integration プレビュー機能が、Keycloak コードベースから個別の拡張プロジェクトに削除されました。

アプリケーションクライアントが http(s) 以外のカスタムスキームを使用している場合、今後は、有効なリダイレクトパターンでそのスキームが明示的に許可されている必要があります。custom スキームを許可するパターン例は、custom:/test、custom:/test/*、または custom:* です。セキュリティ上の理由から、* のような一般的なパターンは、それらをカバーしなくなりました。

以前は、Keycloak は複数の GitHub リポジトリにわたって管理されていました。

複数のリポジトリを持つことは、多くの複雑さと手間をもたらしました。たとえば、1 回の変更で複数のプルリクエストを異なるリポジトリに送信する必要があることがよくありました。

物事を簡素化するために、すべてをメインリポジトリに移行しました。

以前のリリースでプレビューであった Keycloak の FIPS 140-2 サポートが、正式にサポートされるように昇格されました。

アカウントコンソールバージョン 3 が、Keycloak の実験的な機能として利用できるようになりました。このバージョンは、「ユーザープロファイル」機能で作成されたカスタムフィールドをサポートしています。試用して早期フィードバックを提供したい場合は、次のように有効にできます。

非推奨アダプターの削除の一環として、Keycloak Policy Enforcer がアダプターのコードベースから個別の依存関係に抽出されました。

この依存関係を提供することにより、ポリシーエンフォーサーをお好みの Java スタックと統合できるようにすることを期待しています。

また、Wildfly Elytron で保護された Jakarta アプリケーションでポリシーエンフォーサーを有効にするための組み込みサポートも提供します。

現時点では、クイックスタートとドキュメントをまだ作成中のため、この依存関係はまだ GA ではありません。

この作業は、非推奨のアダプターを使用している既存のアプリケーションには影響を与えないはずです。= デフォルトで利用可能な Javascript エンジン

以前のバージョンでは、Keycloak を Java 17 で Javascript プロバイダーとともに使用する場合、Nashorn javascript エンジンをディストリビューションに追加する必要がありました。Nashorn javascript エンジンは Keycloak サーバーでデフォルトで利用できるようになったため、これは不要になりました。

Keycloak 19 では、新しい管理コンソールが新しいデフォルトの管理コンソールに昇格し、古い管理コンソールは非推奨になりました。このリリースでは、古い管理コンソールは完全に削除されました。

Keycloak は、Prometheus 形式でメトリクスをエクスポートするオプションのメトリクスエンドポイントを提供します。このリリースでは、このデータを提供する実装が SmallRye から Micrometer に切り替えられました。この変更により、メトリクスは名前が変更されました。

詳細については、移行ガイドを参照してください。

Java 11 で Keycloak サーバーを実行することは非推奨となり、Keycloak 22 で削除される予定です。

アダプターは、Java 8、Java 11、および Java 17 で引き続きサポートされています。ただし、そう遠くない将来に Java 8 のサポートを削除する予定です。

このリリースでは、Hashicorp vault のすぐに使えるサポートを削除しました。

詳細については、このディスカッションを参照してください。

このリリースより前は、SAML SP メタデータには署名と暗号化の両方の用途に同じキーが含まれていました。このバージョンの Keycloak 以降では、SP メタデータでの暗号化用途には暗号化を目的としたレルムキーのみを含めます。各暗号化キー記述子について、使用されるべきアルゴリズムも指定します。次の表に、サポートされている XML-Enc アルゴリズムと Keycloak レルムキーへのマッピングを示します。詳細については、アップグレードガイドを参照してください。

いくつかの非推奨メソッドがユーザーセッションプロバイダーから削除されました。まだ行っていない場合は、それらの使用箇所を Keycloak 20 リリースの Javadoc に記載されている対応する代替に置き換える必要があります。詳細については、アップグレードガイドを参照してください。

RoleModel の IS_CLIENT_ROLE 検索可能フィールドは非推奨になりました。EXISTS または NOT_EXISTS 演算子で使用される CLIENT_ID 検索可能フィールドに置き換える必要があります。詳細については、Keycloak 21 の JavaDoc を参照してください。

以前のリリースで実験的であった Keycloak の FIPS 140-2 サポートが、プレビューに昇格しました。このプレビューバージョンを作成するために多くの修正と改善が行われました。詳細については、FIPS ドキュメントを参照してください。フィードバックをお待ちしております。

この機能に多大なご協力をいただいた David Anderson、Sudeep Das、および Isaac Jensen に改めて感謝いたします。

リクエストのパスにプロキシサーバーが関与している場合に、プロキシによって追加された情報が変更または失われるのを防ぐために、非標準の X-Forwarded-* を認識することに加えて、Keycloak は同じ目的で標準の Forwarded ヘッダーを活用できるようになりました。

詳細については、リバースプロキシの使用ガイドを参照してください。

プロキシが Keycloak ノードへのリクエストを行うときに、Forwarded ヘッダーもオーバーライドしていることを確認してください。

セキュリティを強化するために、Keycloak コンテナイメージは 2 つの方法で変更されました。1 つ目は、UBI8 ではなく UBI9 ベースになったことです。2 つ目は、以前に使用されていた -minimal ではなく、-micro に切り替えたことです。

UBI9 への変更は、ほとんどのユーザーに影響を与えません。まれに、glibc エラー CPU does not support x86-64-v2 が表示される場合があります。x86-64-v2 は 2009 年以降のプロセッサから利用可能です。仮想化環境が誤って構成されている場合に、この問題が発生する可能性が最も高くなります。

-minimal から -micro への変更は、より大きな影響を与える可能性があります。イメージに簡単なカスタマイズを加えるユーザーは違いに気付かないでしょうが、RPM をインストールするユーザーは、その方法を変更する必要があります。コンテナ内での Keycloak の実行ガイドが更新され、その方法が示されています。

これらの変更の結果、Keycloak コンテナイメージに影響を与える既知の CVE が 82% 削減されました!

Keycloak 17.0.0 では、新しい Quarkus ベースの Keycloak ディストリビューションが導入され、WildFly ベースのディストリビューションは非推奨になりました。このリリースでは、WildFly ディストリビューションは削除され、サポートされなくなりました。

WildFly ディストリビューションをまだ使用している場合は、できるだけ早く Quarkus ディストリビューションに移行することを強くお勧めします。詳細については、移行ガイドを参照してください。

Quarkus ベースのディストリビューション用の新しい Keycloak Operator がプレビュー機能ではなくなったことを発表できてうれしく思います。いくつかの機能追加と多数の改善を行いましたが、その一部は破壊的な変更をもたらしました。

Keycloak は、サーバーとアダプターの両方で OpenJDK 17 をサポートするようになりました。

WildFly ベースのディストリビューションの削除により、OpenJDK 8 で Keycloak サーバーを実行するためのサポートはなくなりました。また、Keycloak 21 で OpenJDK 8 の Keycloak アダプターのサポートを削除する予定です。

Keycloak 22 以降では、最新の OpenJDK LTS リリースのみをサポートし、最新の OpenJDK リリースも迅速にサポートすることを目指しています。つまり、Keycloak 22 では Keycloak サーバーの OpenJDK 11 サポートも削除する予定です。

このリリースでは、フロントエンドリクエストと管理コンソールのベース URL を設定するための 2 つの追加サーバーオプションを導入しています。

詳細については、ホスト名の設定ガイドを参照してください。

このリリースでは、Linux で実行する場合と同じエクスペリエンスを提供するために、kc.bat に重要な変更を加えています。

Keycloak は、開発目的で H2 データベースドライバーを同梱しています。これは開発目的のみを意図しているため、本番環境では絶対に使用しないでください。

このリリースでは、H2 ドライバーがバージョン 1.x からバージョン 2.x にアップグレードされました。

アプリケーションは、keycloak.js を Keycloak サーバーから直接ロードできます。JavaScript ライブラリをこの方法でロードすることはベストプラクティスとは見なされないため、この機能を無効にできるフィーチャーガードが追加されました。

Keycloak 21 では、このオプションを非推奨とし、Keycloak 22 では、Keycloak サーバーから keycloak.js をロードする機能を完全に削除する予定です。

以前のリリースでは、ユーザーに表示される OTP アプリケーションのリストは Keycloak にハードコードされていました。OTP Application SPI の導入により、組み込みの OTP アプリケーションを無効にしたり、カスタム OTP アプリケーションを追加したりすることが可能になりました。

カスタムアイデンティティプロバイダーが、ログインページで使用されるアイコンを設定できるようになりました。Klaus Betz に感謝します。彼はAppleID でのログインをサポートする Keycloak の拡張機能もメンテナンスしています。

FIPS 140-2 対応環境への Keycloak のデプロイに対する実験的サポートが追加されました。試用方法の詳細を記載したブログ投稿が、リリース直後に公開される予定です。フィードバックをお待ちしております。

この機能の一部に貢献してくれた David Anderson に感謝します。また、インスピレーションとして使用された最初のプロトタイプ作成の努力をしてくれた Sudeep Das と Isaac Jensen にも感謝します。

Admin REST API を介して属性でグループを検索できるようになりました。この貢献をしてくれた Alice に感謝します。

ユーザーがアカウントコンソールで自分のグループメンバーシップを表示できるようにすることが可能になりました。この貢献をしてくれた cgeorgilakis に感謝します。

いくつかの非推奨メソッドがデータプロバイダーおよびモデルから削除されました。まだ行っていない場合は、それらの使用箇所を Keycloak 19 リリースの Javadoc に記載されている対応する代替に置き換える必要があります。詳細については、アップグレードガイドを参照してください。

一部の Keycloak OpenID Connect アダプターは寿命が尽き、このリリースには含まれていません。

新しい管理コンソールがデフォルトの管理コンソールに昇格し、古いコンソールは非推奨になりました。古いコンソールは Keycloak 21 で削除されます。

Keycloak ストレージが変更されており、現在のストレージは引き続きサポートされていますが、最終的には真新しい実装に置き換えられます。この変更により、クラウドネイティブストレージのサポート、ダウンタイムなしの機能、ユーザー以外の追加領域のカスタムストレージの実装のサポートが向上します。

これは、現在のストアのサポートされている機能のいくつかの深い変更が *レガシー* 機能になることを意味します。レガシーストアと新しいストアを同時に使用することはできません。一度にアクティブにできるストアは 1 つだけです。

最も目に見える変更は、User Storage SPI が新しいストレージ API である Map Storage API と互換性がないことです。したがって、User Storage SPI はレガシーストアで非推奨となり、keycloak-model-legacy という別のモジュールに移動します。この変更は、特にユーザーフェデレーションおよびカスタムユーザープロバイダーに関連する領域など、いくつかの領域に影響を与えます。

さらに、API が統合され、ストレージレイヤーの詳細は REST サービスレイヤーに対して透過的になります。具体的には、サービスはキャッシュされたオブジェクトとキャッシュされていないオブジェクトを区別したり、フェデレーションストレージとローカルストレージを明確に区別したりできなくなります。

したがって、KeycloakSession メソッドを介してローカルストレージまたはキャッシュ内のオブジェクトにアクセスするカスタム拡張機能は、見直す必要があります。詳細については、アップグレードガイドを参照してください。

以前のリリースでは、OIDC ログアウトのサポートを追加しました。このリリースには、他のいくつかの修正と改善が含まれています。ハイライトは次のとおりです。

詳細については、サーバー管理ガイドをご覧ください。

新しいプレビュー機能であるUPDATE_EMAILが追加されました。この機能を有効にし、レルムで対応するフラグを有効にすると、ユーザーは新しいメールアドレスに送信されるリンクをクリックして、メールアドレスの更新を確認する必要があります。詳細については、サーバー管理ガイドをご覧ください。貢献者のRéda Housni Alaoui氏に感謝いたします。

今回のリリースでは、レガシーKeycloak OperatorのKeycloak CRにあるpodDisruptionBudgetフィールドを非推奨としました。Kubernetesバージョン1.25以降にOperatorをデプロイする場合、このオプションフィールドは無視されます。

回避策として、クラスター内にPod Disruption Budgetを手動で作成できます。例:

Kubernetesドキュメントも参照してください。

バージョン19以降、KeycloakはGELFを使用して、ELK、EFK、Graylogなどの集中ロギングソリューションにログを送信することを標準でサポートしています。

すぐに使用を開始するためのドキュメントと例は、ロギングガイドにあります。

今回のリリースでは、真新しいKeycloak Operatorをプレビューとして導入します。レガシーOperatorから全面的に書き直されただけでなく、主なユーザー向け変更点は、使用されるKeycloakディストリビューションです。新しいOperatorはQuarkus版のKeycloakを使用します。それに伴い、API（カスタムリソース定義の形式）が変更されました。インストールと移行の手順を含む詳細については、Operator関連ガイドをご覧ください。

レガシーOperatorは、Keycloak WildFlyディストリビューションがEOLを迎えるKeycloak 20までアップデートを受け取ります。

新しい管理コンソールがプレビューに移行し、Keycloak 19でデフォルトの管理コンソールになる予定です。

新しいコンソールに関する問題や改善提案がありましたら、GitHub Discussionsを通じてお知らせください。

Keycloakはステップアップ認証をサポートするようになりました。この機能はKeycloak 17で追加され、今回のバージョンでさらに改良されました。

詳細については、サーバー管理ガイドをご覧ください。

貢献者のCornelia Lahnsteiner氏とGeorg Romstorfer氏に感謝いたします。

Keycloakは、顧客ポリシーを通じてクライアントシークレットローテーションをサポートするようになりました。この機能はプレビュー機能として利用可能になり、機密クライアントが最大2つのシークレットを同時に使用できるレルムポリシーを提供できるようになります。

詳細については、サーバー管理ガイドをご覧ください。

2要素認証の別の方法としてのリカバリーコードが、プレビュー機能として利用可能になりました。

KeycloakがOpenID Connectログアウト仕様のすべてに完全に準拠するように、いくつかの修正と改善が行われました。

詳細については、サーバー管理ガイドをご覧ください。

KeycloakはWebAuthn IDレス認証をサポートするようになりました。この機能により、セキュリティキーがResident Keysをサポートしている限り、WebAuthnセキュリティキーは認証中にユーザーを識別できます。詳細については、サーバー管理ガイドをご覧ください。貢献者のJoaquim Fellmann氏に感謝いたします。

これに加えて、さらに多くのWebAuthnの改善と修正が行われています。

upload-script機能は、非常に長い間非推奨としてマークされていました。今回のリリースで、完全に削除され、サポートされなくなりました。

これらの機能のいずれかを使用している場合は、

これらの機能に引き続き依存する方法を理解するために、管理インターフェースを通じてスクリプトを管理するのではなく、サーバーにスクリプトをデプロイする方法について、こちらのドキュメントを読むことを検討してください。

Keycloakは、ユーザーが持つことができるセッション数に制限を設けることをサポートするようになりました。制限は、レルムレベルまたはクライアントレベルで設定できます。

詳細については、サーバー管理ガイドをご覧ください。貢献者のMauro de Wit氏に感謝いたします。

SAML ECPプロファイルの悪用のリスクを軽減するため、Keycloakは明示的に許可しないすべてのSAMLクライアントに対してこのフローをブロックするようになりました。プロファイルは、クライアント構成内のECPフローを許可するフラグを使用して有効にできます。詳細については、サーバー管理ガイドをご覧ください。

このリリースには、いくつかの重要なバグ修正が含まれています。さらに、FAPI関連の機能（JARMサポートやCIBAの改善など）への貢献に対して、Leandro José de Bortoli氏に感謝いたします。

Until now, administrators were allowed to upload scripts to the server through the Keycloak Administration Console as well as through the RESTful Admin API.

For now on, this capability is disabled by default and users should prefer to deploy scripts directly to the server. For more details, please take a look at JavaScript Providers.

Keycloak server was upgraded to use WildFly 16 under the covers.

Thanks to tnorimat Keycloak now has support for signing and verifying tokens with PS256.

New built-in client scope to make it easy to issue tokens following the Eclipse MicroProfile specification.

Keycloak server was upgraded to use WildFly 15 under the covers.

It is now possible to fully secure OpenShift 3.11 with Keycloak, including the ability to automatically expose Service Accounts as OAuth clients as clients to Keycloak.

This is currently a technology preview feature.

Until now, Drools policies were enabled by default. But now, this policy type is only available as a technology preview feature and to use it you need to enable the preview profile or the corresponding feature. Take a look at the Authorization Services Guide for more details.

DB2 support has been deprecated for a while. With this release we have removed all support for DB2.

Introduced the ability to specify different session idle and max timeouts for remember me sessions. This enables remember me sessions to live longer than regular sessions.

Large numbers of groups have previously caused issues in the admin console. This is now resolved by the introduction of pagination of groups.

In the past, starting the server could take a long time if there were many offline sessions. This startup time has now been significantly reduced.

The Keycloak server was upgraded to use WildFly 14 under the covers.

Keycloak Gatekeeper provides a security proxy that can be used to secure applications and services without an adapter. It can be installed locally alongside your application or as a sidecar on OpenShift or Kubernetes.

Huge thanks to gambol99 for contributing this work to Keycloak.

The Signature SPI makes it possible to plug-in additional signature algorithms. This enables additional signatures and also enables changing how signatures are generated. For example, using this allows using an HSM device to sign tokens.

Thanks to tnorimat for contributing a significant part of this work.

Alongside the Signature SPI there is now also support for additional signature algorithms.

Keycloak now has support for RS256, RS384, RS512, ES256, ES384, ES512, HS256, HS384 and HS512.

Elliptic Curve Digital Signature Algorithm (ES256/384/512) are very interesting as they provide similar security properties as RSA signatures, but use significantly less CPU.

HMAC (HS256/384/512) are also very useful when you do not want your application to verify the signature itself. Since these are symmetric signatures only Keycloak is able to verify the signature, which requires the application to use the token introspection endpoint to verify tokens.

Thanks to tnorimat for contributing a significant part of this work.

It is now possible to specify the audiences in the tokens issued for OpenID Connect clients. There is also support for verification of audience on the adapter side.

The Keycloak server was upgraded to use WildFly 13 under the covers. This means update of the underlying dependencies and also some changes in the configuration. We now also support WildFly 13 adapter and we upgraded the underlying JDG/Infinispan server version for the Cross-DC setup. See Upgrading Guide for more details.

Having authorization services support in Node.js makes it very easy to do fine-grained central authorization with the Node.js adapter.

The hostname SPI introduces a more flexible way to configure the hostname for Keycloak. There are two built-in providers. The first is request, which uses the request headers to determine the hostname. The second is fixed, which allows configuring a fixed hostname. The latter makes sure that only valid hostnames can be used and also allows internal applications to invoke Keycloak through an alternative URL.

For more details refer to the threat mitigation section in the Server Administration Guide.

The newly added Client Authenticator uses X509 Client Certificates and Mutual TLS to secure a connection from the client. In addition to that the Keycloak Server validates Subject DN field of the client’s certificate.

For this release, we improved policy evaluation performance across the board, increasing reliability and throughput. The main changes we did were related with trying to optimize the policy evaluation path by avoiding unnecessary flows and collect decisions as soon as they happen. We also introduced a policy decision cache on a per-request basis, avoiding redundant decisions from policies previously evaluated.

We are also working on other layers of cache which should give a much better experience. See KEYCLOAK-7952.

In previous versions, permissions were always returned from the server using standard OAuth2 response, containing the access and refresh tokens. In this release, clients can use a response_mode parameter to specify how the server should respond to an authorization request. This parameter accepts two values

The keycloak-nodejs-connect, an adapter for NodeJS, now supports constructs to protect resources based on decisions taken from the server. The new construct allows users to protect their resources using fine-grained permissions as follows

Login with Google now supports the hd parameter to restrict Google logins to a specific hosted domain at Google. When this is specified in the identity provider any login from a different domain is rejected.

Thanks to brushmate for the contribution.

Most HTML output is already escaped for HTML tags, but there are some places where HTML tags are permitted. These are only where admin access is needed to update the value. Even though it would require admin access to update such fields we have added an extra layer of defence and are now escaping unsafe elements like <script>.

We now have support for using browser tab and universal links in the JavaScript adapter for Cordova. This enables SSO between multiple applications as well as increases security.

Thanks to gtudan for the contribution.

The SAML adapter can support multi-tenancy now just like the built-in adapter for OpenID Connect.

In previous versions, it was not possible to create claims in the token using a claim name containing a dot (.) character. Now it is possible to escape the dot character in the configuration, so a claim name with the dot character can be used.

Starting with release 4.1, the Spring Boot starter will be based on the Spring Boot 2 adapter. If you are using an older Spring Boot version, the keycloak-legacy-spring-boot-starter is available.

We added support for Client Scopes, which replaces Client Templates. Client Scopes are a more flexible approach and also provides better support for the OAuth scope parameter.

There are changes related to Client Scopes to the consent screen. The list on the consent screen is now linked to client scopes instead of protocol mappers and roles.

See the documentation and migration guide for more details.

We now have a partial implementation of the specification OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens . More accurately we have support for the Certificate Bound Access Tokens. If your confidential client is able to use 2-way SSL, Keycloak will be able to add the hash of the client certificate into the tokens issued for the client. At this moment, it’s just the Keycloak itself, which verifies the token hashes (for example during refresh token requests). We plan to add support to adapters as well. We also plan to add support for Mutual TLS Client Authentication.

Thanks to tnorimat for the contribution.

Keycloak にテーマをホットデプロイすることが、通常のプロバイダーデプロイメントを通じて可能になりました。テーマリソースのサポートも追加され、テーマを作成しなくても追加のテンプレートやリソースを追加できます。これは、認証フローに追加のページを追加する必要があるカスタム認証機構に役立ちます。

特定のクライアントのテーマをオーバーライドするサポートも追加しました。ニーズに合わない場合は、テーマを選択するためのカスタムロジックを実装できる新しいテーマセレクターSPIもあります。

Instagram でログインするサポートを追加しました。hguerrero 氏の貢献に感謝します。

以前は管理コンソールでユーザーをIDで検索するには、URLを編集する必要がありました。ユーザー検索フィールドで直接検索できるようになりました。