第10章 SSO プロトコル

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

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

Red Hat Single Sign-On は、Proof Key for Code Exchange 仕様もサポートします。

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

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

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

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

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

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

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

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

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

また、Securing Applications and Services Guide の Backchannel Authentication Endpoint section および Client Initiated Backchannel Authentication Grant section など、Red Hat Single Sign-On ドキュメントの他の箇所も参照してください。

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="https://backend.internal.example.com/auth"/>
        </properties>
    </provider>
</spi>

POST [delegation_reception]

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

これはブラウザーベースのログアウトです。アプリケーションは、Red Hat Single Sign-On から定期的にセッションステータス情報を取得します。Red Hat Single Sign-On でセッションが終了すると、アプリケーションは通知し、独自のログアウトをトリガーします。

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

ユーザーがログアウトエンドポイントにリダイレクトされると、Red Hat Single Sign-On はクライアントにログアウトリクエストを送信して、ローカルユーザーセッションを無効にし、ログアウトプロセスが終了したらユーザーを何らかの 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 Single Sign-On はログアウト要求をクライアントに送信する必要はありません。これらのクライアントは、ブラウザーの SSO セッションがログアウトしていることを自動的に検出します。

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

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

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