2025年4月11日
リリースをダウンロードするには、Keycloak ダウンロードにアクセスしてください。
今回のリリースでは、標準トークン交換のサポートが追加されました。トークン交換機能は長い間プレビュー段階でしたが、ついに標準トークン交換をサポートできることを嬉しく思います。現在のところ、これはトークン交換仕様に準拠した内部トークンから内部トークンへの交換に限定されています。アイデンティティブローカリングやサブジェクトのなりすましに関連するユースケースはまだカバーしていません。今後のリリースでは、さらに多くのトークン交換ユースケースをサポートしていきたいと考えています。
詳細については、標準トークン交換を参照してください。
以前の Keycloak バージョンで使用されていたレガシートークン交換からのアップグレード方法については、アップグレードガイドを参照してください。
このリリースでは、新しいバージョンのきめ細かい管理者権限のサポートが導入されました。バージョン 2 (V2) は、レルム内での管理アクセスに対する柔軟性と制御を強化します。この機能により、管理者は広範な管理者ロールに依存することなく、ユーザー、グループ、クライアント、およびロールの管理権限を定義できます。V2 は、以前のバージョンと同じレベルのレルムリソースへのアクセス制御を提供し、将来のバージョンでその機能を拡張する予定です。主なポイントは次のとおりです。
集中管理コンソール管理 - 新しい権限セクションが導入され、管理コンソールのさまざまな場所に移動することなく、単一の場所から管理できるようになりました。
管理性の向上 - 管理者は、レルムリソースの権限モデルを構築する際に、権限をより簡単に検索および評価できます。
リソース固有およびグローバル権限 – 権限は、個々のリソース（特定のユーザーやグループなど）またはリソースタイプ全体（すべてのユーザーやすべてのグループなど）に対して定義できます。
明示的な操作スコープ – 権限は独立しており、操作間の隠れた依存関係がなくなりました。管理者は各スコープを明示的に割り当てる必要があり、暗黙的な関係に関する事前の知識がなくても、何が付与されているかを簡単に確認できます。
レルムごとの有効化 – きめ細かい管理者権限はレルムごとに有効にすることができ、導入と構成をより細かく制御できます。
詳細については、きめ細かい管理者権限を参照してください。
移行の詳細については、アップグレードガイドを参照してください。
便利なメトリクス名のリスト監視ガイドカテゴリに加えて、Grafana でこれらのメトリクスを表示する方法に関するガイドも含まれるようになりました。このガイドには 2 つのダッシュボードが含まれています。
Keycloak トラブルシューティングダッシュボード - サービスレベルインジケーターとトラブルシューティングに関連するメトリクスを表示します。
Keycloak キャパシティプランニングダッシュボード - Keycloak によって処理される負荷の推定に関連するメトリクスを表示します。
複数のノードをクラスタリングするために、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 は、デフォルトで NetworkPolicy を作成して、Keycloak の分散キャッシュに使用される内部ポートへのトラフィックを制限するようになりました。
これにより、セキュアバイデフォルトのセットアップが強化され、新しいセットアップの構成手順が最小限に抑えられます。
Kubernetes NetworkPolicies ルール構文を使用して、管理および HTTP エンドポイントへのアクセスをさらに制限できます。
詳細については、Operator 高度な構成をお読みください。
https-management-certificates-reload-period オプションを設定して、管理インターフェースの https-management-* オプションによって参照されるキーストア、トラストストア、および証明書ファイルのリロード期間を定義できます。リロードを無効にするには -1 を使用します。デフォルトは https-certificates-reload-period で、デフォルトは 1 時間 (1 時間) です。
詳細については、管理インターフェースの構成ガイドを確認してください。
リクエストされたスコープ、ACR（認証コンテキストクラス参照）などの条件に基づいて認証フローを動的に選択する機能が導入されました。これは、新しい AuthenticationFlowSelectorExecutor と新しい ACRCondition のような条件を組み合わせることにより、クライアントポリシーを使用して実現できます。詳細については、サーバー管理ガイドを参照してください。
OpenID Connect Core Specificationの最新バージョンでは、クライアント認証メソッド private_key_jwt および client_secret_jwt の JWT クライアントアサーションにおけるオーディエンス検証のルールが厳格化されました。Keycloak は、クライアント認証に使用される JWT トークンに単一のオーディエンスが存在することをデフォルトで強制するようになりました。
JWT クライアント認証 Keycloak バージョンでのオーディエンス検証の変更については、アップグレードガイドを参照してください。
Thomas Darimont 氏の貢献に感謝します。
これまで、ユーザー API を使用してユーザー資格情報をクエリすると、ユーザーストレージプロバイダーによって管理される資格情報は返されず、その結果、資格情報が最後に更新された日時などのフェデレーション資格情報に関連付けられた追加のメタデータを取得することができませんでした。
このリリースでは、org.keycloak.credential.CredentialInputUpdater インターフェースに新しいメソッド getCredentials(RealmModel, UserModel) を追加し、ユーザー ストレージ プロバイダーがレルム内の特定のユーザーに対して管理する資格情報を返すことができるようにしました。これにより、ユーザー ストレージ プロバイダーは、資格情報がそれに関連付けられているかどうかを示すだけでなく、管理コンソールを通じてユーザーを管理する際に追加情報を表示できるように追加のメタデータを提供できます。
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 氏に感謝します。
アップグレードする前に、変更の完全なリストについては、移行ガイドを参照してください。