第2章 リリース固有の変更

X-Forwarded-Host ヘッダーにはオプションでポートも含めることができます。以前のバージョンでは、ポートがヘッダーから省略されると、Red Hat build of Keycloak は実際のリクエストポートにフォールバックしていました。たとえば、Red Hat build of Keycloak がポート 8080 でリッスンしていて、リクエストに X-Forwarded-Host: example.com ヘッダーが含まれていた場合、解決された URL は http://example.com:8080 になりました。

これが変更され、ポートが省略されると、解決された URL から削除されます。前の例から解決された URL は http://example.com になります。

これを軽減するには、リバースプロキシーの X-Forwarded-Host ヘッダーにポートを含めるか、X-Forwarded-Port ヘッダーに必要なポートを設定するように指定します。

ディストリビューションに明示的に追加する必要がある Oracle JDBC ドライバーに必要な JAR が変更されました。ojdbc11 JAR を提供する代わりに、Oracle データベースドライバーのインストール に記載されているように、ojdbc17 JAR を使用します。

このバージョンでは、デフォルトである H2 ベースの dev-file データベースの認証情報が変更されました。この開発専用データベースを使用するインスタンスからの移行はサポートされていませんが、データベースのユーザー名とパスワードの古いデフォルトを明示的に指定すると、既存の H2 データベースを引き続き使用できる場合があります。たとえば、keycloak.conf で以下を指定します。

OpenID Connect core specification の最新のドラフトバージョンでは、クライアント認証方法 private_key_jwt および client_secret_jwt の JWT クライアントアサーションにおけるオーディエンス検証のルールが変更されました。

以前は、JWT クライアントアサーションの aud クレームは The Audience SHOULD be the URL of the Authorization Server’s Token Endpoint と緩く定義されていましたが、他の URL の使用が排除されていませんでした。

改訂された OIDC コア仕様では、より厳格なオーディエンスチェックが使用されます (The Audience value MUST be the OP’s Issuer Identifier passed as a string, and not a single-element array.)。

private_key_jwt と client_secret_jwt の両方の JWT クライアント認証オーセンティケーターを適応させて、デフォルトでトークン内のオーディエンスが 1 つだけ許可されるようにしました。現時点では、対象者は、クライアント JWT 認証で使用される発行者、トークンエンドポイント、イントロスペクションエンドポイント、またはその他の OAuth/OIDC エンドポイントになります。ただし、現在許可されているオーディエンスは 1 つだけなので、他の無関係なオーディエンス値を使用できません。つまり、JWT トークンは実際には Red Hat build of Keycloak によるクライアント認証でのみ有効になります。

この厳格なオーディエンスチェックは、OIDC ログインプロトコル SPI の新しいオプションを使用して、以前のより緩いチェックに戻すことができます。サーバーが以下のオプションで起動された場合、引き続き JWT で複数のオーディエンスを使用することができます。

--spi-login-protocol-openid-connect-allow-multiple-audiences-for-jwt-client-authentication=true

このオプションは今後削除される可能性があることに注意してください。おそらく、Red Hat build of Keycloak 27 で削除されます。したがって、このオプションを使用する代わりに、単一のオーディエンスを使用するようにクライアントを更新することを強く推奨します。また、クライアント認証のために JWT を送信するときは、今後のバージョンの OIDC 仕様と互換性があるため、クライアントがオーディエンスに発行者 URL を使用することを推奨します。

バージョン 26.2.x では、次の変更が既存の機能に新たなサポートを提供する主要な改善点です。

このリリースでは、Red Hat build of Keycloak は 標準トークン交換 (機能 token-exchange-standard:v2) のサポートを追加しました。過去の Red Hat build of Keycloak リリースでは、Red Hat build of Keycloak にはプレビュートークン交換機能しかありませんでした。この機能は現在 レガシートークン交換 (機能 token-exchange:v1) と呼ばれています。レガシートークン交換はまだプレビュー段階であり、以前のリリースと同じように機能します。内部間トークン交換 を使用していた場合は、新しい標準トークン交換への移行を検討してください。

レガシートークン交換を引き続き使用する場合、標準のトークン交換機能を無効にする必要はありません。クライアントは、Red Hat build of Keycloak クライアントで標準トークン交換が有効になっている場合にのみ、標準トークン交換を使用します。ただし、標準のトークン交換への移行が推奨されます。これは公式にサポートされている方法であり、機能拡張の優先事項です。

新しい標準トークン交換への移行を計画する際には、次の注意事項を考慮してください。

2 種類のトークン交換の動作における次の追加の変更を考慮してください。

現在、オフラインセッションから発行されたサブジェクトトークンを使用して、オフライントークンのリクエストやリフレッシュトークンの交換を行うことはサポートされていません。可能な場合は、リフレッシュトークンではなくアクセストークンを交換することを推奨します。

Red Hat build of Keycloak は、Fine-grained admin permissions V2 を導入することで、管理者権限に対する認可モデルをさらに柔軟で使いやすく改善しています。