第10章 SSO プロトコル

認可コードフローはブラウザーベースのプロトコルで、ブラウザーベースのアプリケーションの認証および認可に適しています。ブラウザーのリダイレクトを使用してアイデンティティーおよびアクセストークンを取得します。

機密性が要求される クライアントは、トークンの一時コードを交換する際にクライアントシークレットを提供します。パブリッククライアントは、クライアントシークレットの提供を要求されません。パブリック クライアントは、HTTPS が厳格に適用され、クライアントに登録されているリダイレクト URI が厳格に制御される場合に保護されます。HTML5/JavaScript クライアントは、クライアントシークレットを HTML5/JavaScript クライアントへ安全に送信する方法がないため、パブリック クライアントである必要があります。詳細は、クライアントの管理 の章を参照してください。

Red Hat build of Keycloak は、Proof Key for Code Exchange 仕様もサポートします。

インプリシットフローはブラウザーベースのプロトコルです。これは Authorization Code Flow と似ていますが、要求が少なく、更新トークンはありません。

このプロトコルは以下のように動作します。

Direct Access Grants は、ユーザーの代わりにトークンを取得するために REST クライアントによって使用されます。これは、以下の項目を含む HTTP POST リクエストです。

HTTP 応答には、アイデンティティー、アクセス、および 更新 トークンが含まれます。

Client Credentials Grant は、外部ユーザーの代わりに機能するトークンを取得するのではなく、クライアントに関連付けられたサービスアカウントのメタデータおよびパーミッションに基づいてトークンを作成します。Client Credentials Grants は REST クライアントによって使用されます。

詳細は、サービスアカウント の章を参照してください。

デフォルトでは、Red Hat build of Keycloak は、ほとんどのフローからのトークン応答で更新トークンを返します。いくつかの例外としては、上で説明した暗黙的なフローまたはクライアント認証情報の付与があります。

リフレッシュトークンは、SSO ブラウザーセッションのユーザーセッションに関連付けられており、ユーザーセッションの有効期間中有効です。ただし、そのクライアントは指定された間隔ごとに少なくとも 1 回はリフレッシュトークン要求を送信する必要があります。そうでない場合、セッションは "アイドル" とみなされ、期限切れになる可能性があります。詳細は、タイムアウトのセクション を参照してください。

Red Hat build of Keycloak は offline tokens をサポートしています。これは通常、対応するブラウザー SSO セッションがすでに期限切れであっても、クライアントがリフレッシュトークンを使用する必要がある場合に使用できます。

これは、入力機能が制限されているか、適切なブラウザーがないインターネット接続デバイスで実行されているクライアントによって使用されます。以下は、プロトコルの概要です。

この機能は、OAuth 2.0 の認可コード付与のようなユーザーのブラウザーを介したリダイレクトを行わずに、OpenID プロバイダーと直接通信して認証フローを開始したいクライアントによって使用されます。以下は、プロトコルの概要です。

管理者は、Client Initiated Backchannel Authentication (CIBA) 関連の操作をレルムごとに CIBA ポリシー として設定できます。

また、アプリのセキュリティー 保護 セクションの backchannel Authentication Endpoint および Client Initiated Backchannel Authentication Grant など、Keycloak ドキュメントの Red Hat ビルドの他の部分も参照してください。

kc.[sh|bat] start --spi-ciba-auth-channel-ciba-http-auth-channel-http-authentication-channel-uri=https://backend.internal.example.com

POST [delegation_reception]

POST /realms/[realm]/protocol/openid-connect/ext/ciba/auth/callback

これはブラウザーベースのログアウトです。アプリケーションは、Red Hat build of Keycloak から定期的にセッションステータス情報を取得します。Red Hat build of Keycloak でセッションが終了すると、アプリケーションはそれを認識して自身のログアウトをトリガーします。

これもブラウザーベースのログアウトで、Red Hat build of Keycloak でユーザーを特定のエンドポイントにリダイレクトすることでログアウトが開始されます。通常、Red Hat build of Keycloak を使用してユーザー認証を行っていたアプリケーションのページで、ユーザーが Log Out リンクをクリックすると、このリダイレクトが発生します。

ユーザーがログアウトエンドポイントにリダイレクトされると、Red Hat build of Keycloak はクライアントにログアウト要求を送信してローカルユーザーセッションを無効にし、ログアウトプロセスが完了するとユーザーをいずれかの URL にリダイレクトする可能性があります。id_token_hint パラメーターが使用されない場合に、ユーザーはオプションでログアウトを確認するように要求される場合があります。ログアウト後、指定された post_logout_redirect_uri がパラメーターとして提供されている限り、ユーザーは自動的にリダイレクトされます。post_logout_redirect_uri が含まれている場合には、client_id または id_token_hint パラメーターのいずれかを含める必要があります。また、post_logout_redirect_uri パラメーターは、クライアント設定で指定された Valid Post Logout Redirect URI のいずれかと一致する必要があります。

クライアントの設定に応じて、ログアウト要求はフロントチャネルまたはバックチャネルを介してクライアントに送信できます。前のセクションで説明したセッション管理に依存するフロントエンドブラウザークライアントの場合、Red Hat build of Keycloak はログアウト要求をクライアントに送信する必要はありません。これらのクライアントは、ブラウザーの SSO セッションがログアウトしていることを自動的に検出します。

フロントチャネルを介してログアウト要求を受信するようにクライアントを設定するには、Front-Channel Logout クライアント設定を確認します。この方法を使用するときは、次のことを考慮してください。

クライアントでフロントチャネルログアウトが有効になっていない場合、Red Hat build of Keycloak はまず バックチャネルログアウト URL を使用して、バックチャネル経由でログアウト要求を送信しようとします。定義されていない場合、サーバーは 管理 URL を使用するようにフォールバックします。

これは、Red Hat build of Keycloak とクライアント間の直接バックチャンネル通信を使用する非ブラウザーベースのログアウトです。Red Hat build of Keycloak は、ログアウトトークンが含まれる HTTP POST リクエストを、Keycloak にログインしたすべてのクライアントに送信します。これらのリクエストは、Red Hat build of Keycloak で登録されたバックチャンネルログアウト URL に送信され、クライアント側でのログアウトをトリガーすると想定されています。