5.6. アプリケーション起点のアクション


アプリケーション起点のアクション (AIA) を使用すると、クライアントアプリケーションは、ユーザーに Red Hat build of Keycloak でアクションを実行するように要求できます。通常、OIDC クライアントアプリケーションは、ユーザーにログインを要求する場合、OIDC セクション で説明されているように、そのユーザーをログイン URL にリダイレクトします。ログイン後、ユーザーはクライアントアプリケーションにリダイレクトされます。ユーザーは、前のセクション で説明したように管理者によって要求されたアクションを実行し、すぐにアプリケーションにリダイレクトされます。しかし、AIA を使用すると、クライアントアプリケーションは、ログイン時にユーザーに対して特定の必須アクションを要求できます。これは、ユーザーがクライアント上ですでに認証されており、アクティブな SSO セッションがある場合でも実行できます。これは、要求されたアクションを含む値を持つ kc_action パラメーターを OIDC ログイン URL に追加することによってトリガーされます。たとえば、kc_action=UPDATE_PASSWORD パラメーターです。

ユーザーはアプリケーションによって開始されたアクションをキャンセルできます。この場合、ユーザーはクライアントアプリケーションにリダイレクトされます。リダイレクト URI には、キャンセルされたアクションの名前を含むクエリーパラメーター kc_action_status=cancelledkc_action が含まれます。

注記

kc_action および kc_action_status パラメーターは、OIDC 仕様でサポートされていない Red Hat build of Keycloak のプロプライエタリーメカニズムです。

注記

アプリケーション起点のアクションは、OIDC クライアントに対してのみサポートされます。

したがって、AIA を使用する場合、フローの例は次のようになります。

  • クライアントアプリケーションは、kc_action=UPDATE_PASSWORD などの追加パラメーターを使用して、ユーザーを OIDC ログイン URL にリダイレクトします。
  • 認証フローのセクション で説明されているように、常に ブラウザー フローがトリガーされます。ユーザーが認証されなかった場合、そのユーザーは通常のログイン時と同様に認証する必要があります。ユーザーがすでに認証されている場合、そのユーザーは、アクティブに再認証して認証情報を再度入力する必要なく、SSO Cookie によって自動的に再認証される可能性があります。この場合、そのユーザーは特定のアクション (この場合はパスワードの更新) を実行する画面に直接リダイレクトされます。ただし、場合によっては、ユーザーが SSO Cookie を持っている場合でも、アクティブな再認証が必要になります (詳細は こちら を参照してください)。
  • 特定のアクション (この場合は update password) の画面がユーザーに表示されるため、ユーザーは特定のアクションを実行する必要があります。
  • その後、ユーザーはクライアントアプリケーションにリダイレクトされます。

AIA は、Red Hat build of Keycloak アカウントコンソール でパスワードの更新を要求したり、OTP や WebAuthn などの他の認証情報をリセットしたりするために使用されることに注意してください。

警告

パラメーター kc_action が使用されたとしても、ユーザーが常にアクションを実行すると想定するだけでは不十分です。たとえば、ユーザーがブラウザーの URL から kc_action パラメーターを手動で削除した可能性があります。したがって、クライアントが kc_action=CONFIGURE_TOTP を要求した後、ユーザーがアカウントの OTP を持っているという保証はありません。ユーザーが 2 要素認証を設定したことを検証する場合は、クライアントアプリケーションでそれが設定されていることを確認する必要があります。たとえば、トークン内の acr のようなクレームを確認します。

5.6.1. AIA 中の再認証

アクティブな SSO セッションによりユーザーがすでに認証されている場合、通常、そのユーザーはアクティブに再認証する必要はありません。ただし、そのユーザーが 5 分以上前にアクティブに認証されている場合、クライアントは AIA が要求されたときに再認証を要求できます。このガイドラインには次のような例外があります。

  • Required actions タブ で、必須アクションごとに、必須アクション自体の最大有効期間を設定できます。ポリシーが設定されていない場合は、デフォルトで 5 分に設定されます。
  • delete_account アクションでは、常にユーザーが能動的に再認証する必要があります。
  • UPDATE_PASSWORD アクションが、設定された 認証の最大有効期間のパスワードポリシー に従って、ユーザーが能動的に再認証するよう要求する可能性があります。ポリシーが設定されていない場合は、特定の必須アクションを設定するときに、Required actions tab で必須アクション自体にポリシーを設定することもできます。これらのいずれの場所でもポリシーが設定されていない場合は、デフォルトで 5 分に設定されます。
  • より短い再認証を使用する場合は、指定されたより短い値を持つ max_age などのパラメータークエリーパラメーターを使用するか、最終的には prompt=login を使用できます。これにより、OIDC 仕様で説明されているように、ユーザーによる能動的な再認証が常に要求されます。デフォルトの 5 分 (または必須アクション用に特別に設定した値) よりも長い値の max_age を使用することはサポートされていないことに注意してください。現在、max_age は、値をデフォルトの 5 分より短くするためにのみ使用できます。
  • ステップアップ認証が 有効になっていて、操作が認証情報の追加または削除である場合、指定された認証情報に対応するレベルの認証が必要になります。この要件は、ユーザーがすでに特定のレベルの認証情報を持っている場合に存在します。たとえば、認証フローで otpwebauthn が 2 番目の要素認証子として設定されていて (両方とも認証フローのレベル 2)、ユーザーがすでに 2 番目の要素認証情報 (この場合は otp または webauthn) を持っていると、ユーザーは既存の 2 番目の要素認証情報を使用して認証し、別の 2 番目レベルの認証情報を追加する必要があります。同様に、既存の 2 番目の要素認証情報 (この場合は otp または webauthn) を削除する場合は、既存の 2 番目の要素レベルの認証情報による認証が必要になります。この要件はセキュリティー上の理由から存在します。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hat
トップに戻る