8.3. 認証フロー
authentication flow は、ログイン、登録、その他の Red Hat build of Keycloak ワークフロー中の認証、画面、アクションのコンテナーです。
8.3.1. 組み込みフロー
Red Hat build of Keycloak には、いくつかのビルトインフローがあります。これらのフローは変更できませんが、フローの要件をニーズに合わせて変更することができます。
手順
- メニューで Authentication をクリックします。
- リスト内の Browser 項目をクリックして詳細を表示します。
ブラウザーのフロー
8.3.1.1. 認証タイプ
実行する認証またはアクションの名前。認証がインデントされると、これはサブフローにあります。これは、親の動作によって実行されるか、実行されていない可能性があります。
Cookie
ユーザーが初めてログインに成功すると、Red Hat build of Keycloak はセッション Cookie を設定します。クッキーがすでに設定されている場合、この認証タイプは成功します。Cookie プロバイダーが成功を返し、このフローレベルのそれぞれの実行が alternative であるため、Red Hat build of Keycloak は他の実行を行いません。これにより、ログインに成功します。
Kerberos
このオーセンティケーターはデフォルトで無効になっており、ブラウザーフローではスキップされます。
アイデンティティープロバイダーのリダイレクター
このアクションは、Actions > Config リンクで設定されます。Identity Brokering のために別の IdP にリダイレクトします。
フォーム
このサブフローは 代替 としてマークされているため、Cookie 認証タイプ が渡されると実行されません。このサブフローには、実行する必要がある追加の認証タイプが含まれています。Red Hat build of Keycloak は、このサブフローの実行をロードして処理します。
最初の実行は、ユーザー名とパスワードのページをレンダリングする認証タイプである Username Password Form です。これは必須と識別されているため、ユーザーは有効なユーザー名とパスワードを入力する必要があります。
2 回目の実行は、Browser - Conditional OTP サブフローです。このサブフローはconditional で、ユーザー設定の実行結果 Condition - User Configured 実行に応じて実行されます。結果が true の場合、Red Hat build of Keycloak はこのサブフローの実行をロードして処理します。
次の実行は、Condition - User Configured 認証です。この認証は、Red Hat build of Keycloak がそのフロー内で、そのユーザーの他の実行を設定しているか確認します。Browser - Conditional OTP サブフローは、ユーザーが OTP 認証情報が設定された場合にのみ実行されます。
最後の実行は OTP Form です。Red Hat build of Keycloak はこの実行を required としてマークしますが、conditional サブフローでのセットアップのため、ユーザーが OTP 認証情報をセットアップしている場合にのみ実行されます。そうでない場合は、OTP フォームは表示されません。
8.3.1.2. 要件
アクション実行を制御するラジオボタンのセット。
8.3.1.2.1. 必須
フローで 必須 要素がすべて順次実行される必要があります。フローは、必須要素が失敗すると終了します。
8.3.1.2.2. 代替方法
フローが正常に実行されると評価するには、単一の要素のみを正常に実行する必要があります。Required flow 要素にはフローに successful というマークを付けるだけで十分であるため、Required フロー要素が含まれるフロー内の Alternative flow 要素は実行されません。
8.3.1.2.3. Disabled
要素は、フローに successful というマークを付けることはできません。
8.3.1.2.4. 条件付き
この要件タイプはサブフローにのみ設定されます。
- Conditional サブフローには実行が含まれます。これらの実行は論理ステートメントに評価する必要があります。
- すべての実行が true として評価されると、Conditional サブフローは必須として動作します。
- すべての実行が false と評価されると、Conditional サブフローは Disabled として機能します。
- 実行を設定しない場合、Conditional サブフローは Disabled として機能します。
- フローに実行が含まれ、かつ Conditional に設定されていない場合、Red Hat build of Keycloak は実行を評価せず、実行は機能的に Disabled とみなされます。
8.3.2. フローの作成
フローの設計時に、重要な機能およびセキュリティー上の考慮事項が適用されます。
フローを作成するには、以下を実行します。
手順
- メニューで Authentication をクリックします。
- Create flow をクリックします。
既存のフローをコピーおよび変更できます。"アクションリスト" (行の最後にある 3 つの点) をクリックし、Duplicate をクリックして、新しいフローの名前を入力します。
新しいフローを作成する場合は、まず以下のオプションでトップレベルフローを作成する必要があります。
- Name
- フローの名前。
- Description
- フローに設定できる説明。
- Top-Level Flow Type
- フローのタイプ。タイプ クライアントは、クライアント (アプリケーション) の認証にのみ使用されます。それ以外の場合はすべて、basic を選択します。
トップレベルフローの作成
Red Hat build of Keycloak がフローを作成すると、Red Hat build of Keycloak に Add step ボタンと Add sub-flow ボタンが表示されます。
空の新規フロー
3 つの要因により、フローとサブフローの動作が決定されます。
- フローおよびサブフローの構造。
- フロー内での実行
- サブフローおよび実行内で設定される要件。
リセットメールの送信から OTP の検証まで、実行にはさまざまなアクションを設定できます。Add step ボタンを使用して実行を追加します。
認証実行の追加
認証実行では、必要に応じて参照値を設定できます。これは、Authentication Method Reference (AMR) プロトコルマッパーで利用して、OIDC アクセストークンと ID トークンに amr クレームを入力するために使用できます (AMR クレームの詳細は、RFC-8176 を参照してください)。Authentication Method Reference (AMR) プロトコルマッパーがクライアント用に設定されている場合、認証フロー中にユーザーが正常に完了したオーセンティケーター実行の参照値が amr クレームに入力されます。
オーセンティケーターの参照値の追加
自動実行とインタラクティブな実行の 2 種類の実行があります。自動実行 は Cookie 実行に類似し、フローのアクションを自動的に実行します。インタラクティブな実行は、入力を取得するためにフローを停止します。正常に実行されると、ステータスを success に設定します。フローが完了するには、ステータスが success の実行が少なくとも 1 つ必要です。
Add sub-flow ボタンを使用して、サブフローを最上位のフローに追加できます。Add sub-flow ボタンをクリックすると、Create Execution Flow ページが表示されます。このページは Create Top Level Form ページに似ています。違いは、Flow Type に basic (デフォルト) と form がある点です。form タイプは、組み込み Registration フローに似た、ユーザーのフォームを生成するサブフローを構築します。サブフローが成功するかどうかは、含まれるサブフローを含め、実行がどのように評価されるかによります。サブフローがどのように機能するかの詳細な説明については、実行要件 セクションを参照してください。
実行を追加したら、要件の値が正しいことを確認します。
フロー内のすべての要素には、要素の横に Delete オプションがあります。一部の実行には、実行を設定するための ⚙️ メニュー項目 (歯車アイコン) があります。Add step および Add sub-flow リンクで、サブフローに実行とサブフローに追加することもできます。
実行の順序は重要であるため、名前をドラッグして実行とサブフローを上下に移動できます。
認証フローを設定するときは、設定を適切にテストして、セットアップにセキュリティーホールが存在しないことを確認してください。さまざまなコーナーケースをテストすることが推奨されます。たとえば、認証前にユーザーのアカウントからさまざまな認証情報を削除するときに、ユーザーの認証動作をテストすることを検討してください。
たとえば、OTP フォームや WebAuthn オーセンティケーターなどの第 2 要素オーセンティケーターがフローで REQUIRED として設定されていて、ユーザーが特定のタイプのクレデンシャルを持っていない場合、ユーザーは認証自体の間に特定のクレデンシャルをセットアップできます。この状況は、認証中にユーザーがこの認証情報で認証されないことを意味します。ブラウザー認証の場合は、Password や WebAuthn Passwordless Authenticator などの一部の 1 つの要素認証情報で認証フローを設定してください。
8.3.3. パスワードなしのブラウザーログインフローの作成
フローの作成を説明するために、このセクションでは高度なブラウザーログインフローの作成を説明します。このフローの目的は、ユーザーが、WebAuthn によるパスワードなしの方法でのログインと、パスワードと OTP を使用した二要素認証を選択できるようにすることです。
手順
- メニューで Authentication をクリックします。
- Flows タブをクリックします。
- Create flow をクリックします。
-
名前として
Browser Password-less
を入力します。 - Create をクリックします。
- Add execution をクリックします。
- リストから Cookie を選択します。
- Add をクリックします。
- Cookie 認証タイプの Alternative を選択して、その要件を代替に設定します。
- Add step をクリックします。
- リストから Kerberos を選択します。
- Add をクリックします。
- Add step をクリックします。
- リストから Identity Provider Redirector を選択します。
- Add をクリックします。
- Identity Provider Redirector 認証タイプの Alternative を選択して、その要件を代替に設定します。
- Add sub-flow をクリックします。
- 名前として Forms と入力します。
- Add をクリックします。
Forms 認証タイプの Alternative を選択して、その要件を代替に設定します。
ブラウザーフローの共通部分
- Forms 実行の + メニューをクリックします。
- Add step を選択します。
- リストから Username Form を選択します。
- Add をクリックします。
この段階では、フォームにはユーザー名が必要ですが、パスワードは必要ありません。セキュリティーリスクを回避するために、パスワード認証を有効にする必要があります。
- Forms サブフローの + メニューをクリックします。
- Add sub-flow をクリックします。
-
名前として
Authentication
を入力します。 - Add をクリックします。
- Authentication 認証タイプで Required を選択し、その要件を必須に設定します。
- Authentication サブフローの + メニューをクリックします。
- Add step をクリックします。
- リストから WebAuthn Passwordless Authenticator を選択します。
- Add をクリックします。
- Webauthn Passwordless Authenticator 認証タイプの Alternative を選択して、その要件を代替に設定します。
- Authentication サブフローの + メニューをクリックします。
- Add sub-flow をクリックします。
-
名前として
Password with OTP
を入力します。 - Add をクリックします。
- Password with OTP で Alternative を選択し、その要件を代替に設定します。
- Password with OTP サブフローの + メニューをクリックします。
- Add step をクリックします。
- リストから Password Form を選択します。
- Add をクリックします。
- Password Form 認証タイプで Required を選択し、その要件を必須に設定します。
- Password with OTP サブフローの + メニューをクリックします。
- Add step をクリックします。
- リストから OTP Form を選択します。
- Add をクリックします。
- OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。
最後に、バインディングを変更します。
- 画面上部の Action メニューをクリックします。
- メニューから Bind flow を選択します。
- Browser Flow ドロップダウンリストをクリックします。
- Save をクリックします。
パスワードなしのブラウザーログイン
ユーザー名を入力すると、フローは以下のように機能します。
ユーザーの WebAuthn パスワードレス認証情報が記録されている場合は、これらの認証情報を使用して直接ログインできます。これはパスワードなしのログインです。WebAuthn Passwordless
実行および Password with OTP
フローが Alternative に設定されているため、ユーザーは Password with OTP を選択することもできます。Required に設定されている場合は、ユーザーは WebAuthn、パスワード、および OTP を入力する必要があります。
ユーザーが WebAuthn passwordless
認証で Try another way リンクを選択した場合、ユーザーは Password
と Passkey
(WebAuthn passwordless) のどちらかを選択できます。パスワードを選択すると、ユーザーは続行して、割り当てられた OTP でログインする必要があります。ユーザーに WebAuthn 認証情報がない場合は、ユーザーはパスワードを入力し、続いて OTP を入力する必要があります。ユーザーに OTP 認証情報がない場合は、記録することが要求されます。
WebAuthn Passwordless 実行は Required ではなく Alternative に設定されているため、このフローはユーザーに WebAuthn 認証情報を登録するように要求しません。ユーザーに Webauthn 認証情報を設定するには、管理者がユーザーに必須アクションを追加する必要があります。これを行うには、以下を実行します。
- レルムで Webauthn Register Passwordless で必須アクションを有効にします (WebAuthn のドキュメントを参照)。
- ユーザーの Credentials 管理メニューの Credential Reset 部分を使用して、必須アクションを設定します。
このような高度なフローを作成すると、副次的な影響が生じる可能性があります。たとえば、ユーザーのパスワードをリセットできるようにする場合は、パスワードフォームからアクセスが可能になります。デフォルトの Reset Credentials
フローで、ユーザーはユーザー名を入力する必要があります。ユーザーは Browser Password-less
フローですでにユーザー名を入力しているため、Red Hat build of Keycloak ではこの操作は必要なく、ユーザーエクスペリエンスとしては最適ではありません。この問題を修正するには、以下を行います。
-
Reset Credentials
フローを複製します。たとえば、その名前をReset Credentials for password-less
に設定します。 - Choose user ステップの Delete (ゴミ箱アイコン) をクリックします。
- Action メニューで、Bind flow を選択し、ドロップダウンから Reset credentials flow を選択して、Save をクリックします。
8.3.4. ステップアップメカニズムを使用したブラウザーログインフローの作成
このセクションでは、ステップアップメカニズムを使用して高度なブラウザーログインフローを作成する方法を説明します。ステップ認証の目的は、ユーザーの特定の認証レベルに基づいてクライアントまたはリソースへのアクセスを許可することです。
手順
- メニューで Authentication をクリックします。
- Flows タブをクリックします。
- Create flow をクリックします。
-
Browser Incl Step up Mechanism
を名前として入力します。 - Save をクリックします。
- Add execution をクリックします。
- リストから Cookie を選択します。
- Add をクリックします。
- Cookie 認証タイプの Alternative を選択して、その要件を代替に設定します。
- Add sub-flow をクリックします。
- Auth Flow を名前として入力します。
- Add をクリックします。
- Auth Flow 認証タイプの Alternative をクリックして、その要件を代替に設定します。
最初の認証レベルのフローを設定します。
- Auth Flow の + メニューをクリックします。
- Add sub-flow をクリックします。
-
1st Condition Flow
を名前として入力します。 - Add をクリックします。
- 1st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
- 1st Condition Flow の + メニューをクリックします。
- Add condition をクリックします。
- リストから Conditional - Level Of Authentication を選択します。
- Add をクリックします。
- Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
- ⚙️ (歯車アイコン) をクリックします。
-
Level 1
をエイリアスとして入力します。 -
レベル認証 (LoA) に
1
と入力します。 -
Max Age を 36000 に設定します。この値は秒単位であり、10 時間に相当します。これは、レルムで設定されているデフォルトの
SSO Session Max
タイムアウトです。その結果、ユーザーがこのレベルで認証される場合、後続の SSO ログインはこのレベルを再利用でき、ユーザーセッションが終了するまでユーザーはこのレベルで認証する必要はありません (デフォルトでは 10 時間)。 Save をクリックします。
最初の認証レベルの条件を設定します。
- 1st Condition Flow の + メニューをクリックします。
- Add step をクリックします。
- リストから Username Password Form を選択します。
- Add をクリックします。
これで、2 つ目の認証レベルのフローが設定されます。
- Auth Flow の + メニューをクリックします。
- Add sub-flow をクリックします。
-
2nd Condition Flow
をエイリアスとして入力します。 - Add をクリックします。
- 2st Condition Flow 認証タイプの Conditional をクリックし、その要件を条件に設定します。
- 2nd Condition Flow の + メニューをクリックします。
- Add condition をクリックします。
- 項目リストから Conditional - Level Of Authentication を選択します。
- Add をクリックします。
- Conditional - Level Of Authentication 認証タイプの Required をクリックして、その要件を必須に設定します。
- ⚙️ (歯車アイコン) をクリックします。
-
Level 2
をエイリアスとして入力します。 -
認証レベル (LoA) に
2
と入力します。 - Max Age を 0 に設定します。その結果、ユーザーが認証する場合、このレベルは現在の認証に対してのみ有効ですが、後続の SSO 認証に対しては有効ではありません。したがって、このレベルが要求された場合、ユーザーは常にこのレベルで再度認証する必要があります。
Save をクリックします。
2 つ目の認証レベルの条件を設定する
- 2nd Condition Flow の + メニューをクリックします。
- Add step をクリックします。
- リストから OTP Form を選択します。
- Add をクリックします。
- OTP Form 認証タイプの Required をクリックして、その要件を必須に設定します。
最後に、バインディングを変更します。
- 画面上部の Action メニューをクリックします。
- リストから Bind flow を選択します。
- ドロップダウンから Browser Flow を選択します。
- Save をクリックします。
ステップアップメカニズムによるブラウザーログイン
特定の認証レベルを要求します。
ステップアップメカニズムを使用するには、認証リクエストに要求された認証レベル (LoA) を指定します。claims
パラメーターは、この目的で使用されます。
https://{DOMAIN}/realms/{REALMNAME}/protocol/openid-connect/auth?client_id={CLIENT-ID}&redirect_uri={REDIRECT-URI}&scope=openid&response_type=code&response_mode=query&nonce=exg16fxdjcu&claims=%7B%22id_token%22%3A%7B%22acr%22%3A%7B%22essential%22%3Atrue%2C%22values%22%3A%5B%22gold%22%5D%7D%7D%7D
claims
パラメーターは JSON 表現で指定されます。
claims= { "id_token": { "acr": { "essential": true, "values": ["gold"] } } }
Red Hat build of Keycloak の JavaScript アダプターは、この JSON を簡単に構築し、ログイン要求で送信できるようにサポートします。詳細は、Secur apps セクションの Keycloak JavaScript アダプター を参照してください。
また、claims
パラメーターの代わりに単純なパラメーター acr_values
を使用して、特定のレベルを必須ではないものとして要求することもできます。これは OIDC 仕様で説明されています。
特定のクライアントのデフォルトレベルを設定することもできます。これは、acr_values
パラメーターまたは acr
要求のある claims
パラメーター要求が存在しない場合に使用されます。詳細は、クライアント ACR 設定 を参照してください。
acr_values を数値ではなくテキスト (gold
など) として要求するには、ACR と LoA の間のマッピングを設定します。レルムレベル (推奨) またはクライアントレベルで設定できます。設定については、ACR から LoA へのマッピング を参照してください。
詳細は、公式の OIDC 仕様 を参照してください。
フローロジック
以前に設定された認証フローのロジックは次のとおりです。
クライアントが高い認証レベル、つまり認証レベル 2 (LoA 2) を要求した場合、ユーザーは完全な 2 要素認証 (ユーザー名/パスワード + OTP) を実行する必要があります。ただし、ユーザーがすでに Red Hat build of Keycloak でセッションを持っていて、ユーザー名とパスワード (LoA 1) を使用してログインしている場合、ユーザーには 2 番目の認証要素 (OTP) のみが求められます。
条件の Max Age 時間オプションは、後続の認証レベルが有効である期間 (秒数) を決定します。この設定は、ユーザーが後続の認証中に認証要素を再度提示するように求められるかどうかを決定するのに役立ちます。特定のレベル X が claims
または acr_values
パラメーターによって要求され、ユーザーがすでにレベル X で認証されているが、有効期限が切れている場合 (たとえば、最大年齢が 300 に設定され、ユーザーが 310 秒前に認証された場合)、ユーザーは再認証を求められます。特定のレベルで再度認証します。ただし、レベルが期限切れでない場合、ユーザーは自動的にそのレベルで認証されていると見なされます。
Max Age を値 0 で使用すると、その特定のレベルはこの単一認証でのみ有効です。そのため、そのレベルを要求するすべての再認証では、そのレベルで再度認証する必要があります。これは、アプリケーションでより高いセキュリティーを必要とし (支払いの送信など)、常に特定のレベルでの認証を必要とする操作に役立ちます。
ログイン要求がクライアントからユーザーのブラウザー経由で Red Hat build of Keycloak に送信されるときに、claim
や acr_values
などのパラメーターが URL 内のユーザーによって変更される可能性があることに注意してください。この状況は、クライアントが PAR (プッシュされた認可要求)、要求オブジェクト、またはユーザーが URL のパラメーターを書き換えることを妨げるその他のメカニズムを使用する場合に軽減できます。そのため、認証後に、トークンの acr
が予想されるレベルに対応するように ID トークンを確認することが推奨されます。
パラメーターによって明示的なレベルが要求されていない場合、Red Hat build of Keycloak では、前の例のユーザー名/パスワードなど、認証フローで最初に見つかった LoA 条件での認証が必要になります。ユーザーがそのレベルですでに認証され、そのレベルの有効期限が切れると、ユーザーは再認証する必要はありませんが、トークンの acr
の値は 0 になります。この結果は、OIDC Core 1.0 仕様のセクション 2 で説明されているように、long-lived browser cookie
のみに基づく認証と見なされます。
ユーザーの最初の認証中に、ユーザーがまだレベルを持たないため、Conditional - Level Of Authentication で最初に設定されたサブフローは常に実行されます。したがって、最初のレベルのサブフローには、ユーザー認証に必要な最低限のオーセンティケーターを含めることが推奨されます。さらに、上記の例に示すように、Conditional - Level Of Authentication に異なる値を持つサブフローが、最も低いものから順番に並べられていることを確認します。たとえば、レベル 2 でサブフローを設定してから、レベル 1 の別のサブフローを追加すると、最初の認証時にレベル 2 のサブフローが常に要求されますが、これは望ましい動作ではない可能性があります。
管理者が複数のフローを指定し、異なる LoA レベルをそれぞれに設定し、フローを別のクライアントに割り当てると、競合状況が発生する可能性があります。ただし、ルールは常に同じです。ユーザーに特定のレベルがある場合は、クライアントに接続するためにそのレベルのみが必要になります。LoA が一貫していることを確認するのは管理者次第です。
シナリオ例
- Max Age は、レベル 1 の状態で 300 秒として設定されています。
-
ログイン要求は、acr を要求せずに送信されます。レベル 1 が使用され、ユーザーはユーザー名とパスワードで認証する必要があります。トークンには
acr=1
があります。 -
別のログイン要求は 100 秒後に送信されます。SSO によりユーザーが自動的に認証され、トークンは
acr=1
を返します。 -
さらに 201 秒 (ポイント 2 での認証から 301 秒) 後に別のログイン要求が送信されます。ユーザーは SSO により自動的に認証されますが、レベル 1 が期限切れと見なされるため、トークンは
acr=0
を返します。 -
別のログイン要求が送信されますが、これで、
claims
パラメーターでレベル 1 の ACR が明示的に要求されます。ユーザーはユーザー名/パスワードで再認証するように求められ、その後acr=1
がトークンで返されます。
トークンの ACR クレーム
ACR 要求は、acr
クライアントスコープで定義された acr loa level
のプロトコルマッパーによってトークンに追加されます。このクライアントスコープはレルムのデフォルトのクライアントスコープであるため、レルム内に新しく作成されたすべてのクライアントに追加されます。
トークン内で acr
クレームが必要ない場合、またはトークンを追加するためのカスタムロジックが必要な場合は、クライアントからクライアントスコープを削除できます。
ログイン要求が acr
を essential
クレームとして要求する claims
パラメーターを使用して要求を開始すると、Red Hat build of Keycloak は常に指定されたレベルの 1 つを返すことに注意してください。指定されたレベルの 1 つを返すことができない場合 (たとえば、要求されたレベルが不明であるか、認証フローで設定された条件よりも大きい場合)、Red Hat build of Keycloak はエラーを出力します。
8.3.5. クライアントから要求された認証情報の登録またはリセット
通常、ユーザーがクライアントアプリケーションから Red Hat build of Keycloak にリダイレクトされると、browser
フローがトリガーされます。このフローでは、レルム登録が有効になっていて、ユーザーがログイン画面で Register
をクリックした場合に、ユーザーが 登録 できるようになります。また、レルムに対して Forget password が有効になっている場合、ユーザーはログイン画面で Forget password
をクリックすることができ、これにより Reset credentials
フローがトリガーとなり、ユーザーはメールアドレスの確認後に認証情報をリセットできます。
クライアントアプリケーションがユーザーを Registration 画面または Reset credentials フローに直接リダイレクトすると便利な場合があります。結果のアクションは、ユーザーが通常のログイン画面で Register または Forget password をクリックしたときのアクションと一致します。登録画面または認証情報のリセット画面への自動リダイレクトは、次のように実行できます。
-
クライアントがユーザーを登録に直接リダイレクトする場合、OIDC クライアントは OIDC ログイン URL パス (
/auth
) の最後のスニペットを/registrations
に置き換える必要があります。したがって、完全な URL はhttps://keycloak.example.com/realms/your_realm/protocol/openid-connect/registrations
のようになります。 -
クライアントがユーザーを
Reset credentials
フローに直接リダイレクトすると、OIDC クライアントは OIDC ログイン URL パス (/auth
) の最後のスニペットを/forgot-credentials
に置き換える必要があります。
上記の手順は、クライアントが登録または認証情報リセットフローを直接要求するためにサポートされている唯一の方法です。セキュリティー上の理由から、クライアントアプリケーションが OIDC/SAML フローを回避し、他の Red Hat build of Keycloak エンドポイント (たとえば、/realms/realm_name/login-actions
または /realms/realm_name/broker
下のエンドポイントなど) に直接リダイレクトすることはサポートされておらず、推奨されていません。