第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 では有効とは見なされなくなるため、クライアントは常に最後のリフレッシュレスポンスからリフレッシュトークンを保存する必要があります。これは、タイムアウトセクション で指定されているように、Revoke Refresh token オプションを使用して設定できます。

Red Hat build of Keycloak は、リフレッシュトークンのローテーションが存在しない状況もサポートします。この場合、ログイン時にリフレッシュトークンが返されますが、リフレッシュトークン要求からの後続の応答では新しいリフレッシュトークンは返されません。この方法は、たとえば FAPI 2 ドラフト仕様 で推奨されています。Red Hat build of Keycloak では、クライアントポリシー を使用してリフレッシュトークンのローテーションをスキップできます。一部のクライアントプロファイルに executor の suppress-refresh-token-rotation を追加し、クライアントポリシーを設定して、どのクライアントに対してプロファイルがトリガーされるかを指定できます。つまり、それらのクライアントでは、更新トークンのローテーションがスキップされます。

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

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

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

また、「アプリケーションおよびサービスのセキュリティー保護ガイド」の バックチャネル認証エンドポイント セクションや「アプリケーションおよびサービスのセキュリティー保護ガイド」の クライアントが開始したバックチャネル認証の付与 セクションなど、Red Hat build of Keycloak ドキュメントの他の部分も参照してください。

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 に送信され、クライアント側でのログアウトをトリガーすると想定されています。