第8章 クライアントの管理

OAuth 2.0 Mutual TLS Certificate Bound Access Tokens Enabled

相互 TLS は、TLS ハンドシェイク時に交換されるクライアント証明書でアクセストークンおよび更新トークンをバインドします。これにより、これらのトークンを盗む方法を見つけた攻撃者がトークンを取得することができなくなります。この種類のトークンは holder-of-key トークンと呼ばれます。ベアラートークンとは異なり、holder-of-key トークンの受信側は、トークンの送信側が正当であるかどうかを検証できます。

トークンリクエストで以下の条件が満たされると、Red Hat Single Sign-On はアクセストークンをバインドし、クライアント証明書で更新トークンを取得し、それらを holder-of-key トークンとして発行します。すべての条件が満たされないと、Red Hat Single Sign-On はトークンリクエストを拒否します。

Red Hat Single Sign-On で相互 TLS を有効にするには、「WildFly で相互 SSL の有効化」を参照してください。

以下の場合には、Red Hat Single Sign-On はアクセストークンまたは更新トークンを送信するクライアントを検証します。検証に失敗すると、Red Hat Single Sign-On はトークンを拒否します。

詳細は、OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens の「Mutual TLS Client Certificate Bound Access Tokens」を参照してください。

Proof Key for Code Exchange (PKCE)

攻撃者が正当なクライアントに発行した認可コードを盗むと、PKCE は攻撃者がそのコードに適用されるトークンを受信するのを防ぎます。

管理者は以下の 3 つのオプションを選択できます。

Proof Key for Code Exchange Code Challenge Method

詳細は、OAuth パブリッククライアントによるコード Exchange の RFC 7636 Proof キー を参照してください。

Signed and Encrypted ID Token Support

Red Hat Single Sign-On は、Json Web Encryption (JWE) 仕様に従って ID トークンを暗号化できます。管理者は、クライアントごとに ID トークンの暗号化を行うかどうかを決定できます。この機能は、デフォルトでは無効になっています。

ID トークンを暗号化するキーは、コンテンツ暗号化キー (CEK) と呼ばれます。Red Hat Single Sign-On およびクライアントは、どの CEK が使用されるかと、その配信方法をネゴシエートする必要があります。これを行うには Key Management Mode と呼ばれます。

JWE 仕様は、キー管理モード の 5 種類のキー管理モードを決定します。Red Hat Single Sign-On は、その中における鍵暗号化をサポートします。

Key Encryption では、クライアントは非対称暗号のペアを生成します。公開鍵は CEK の暗号化に使用されます。Red Hat Single Sign-On は、ID トークンごとに CEK を生成し、この生成された CEK で ID トークンを暗号化し、このクライアントの公開鍵でこの CEK を暗号化します。クライアントはこの暗号化された CEK を秘密鍵で復号化し、CEK を復号化して ID トークンを復号化します。そのため、クライアント以外のユーザーは ID トークンを復号化できません。

クライアントは、CEK を Red Hat Single Sign-On で暗号化するために公開鍵を渡す必要があります。Red Hat Single Sign-On は、クライアントが提供する URL からの公開鍵のダウンロードをサポートします。クライアントは、Json Web Keys (JWK) 仕様に従って公開鍵を提供する必要があります。これを実行する方法は、「Confidential Client Credentials」の「Signed JWT」で定義します。詳細な手順は以下のとおりです。

キー暗号化のアルゴリズムは、Json Web Algorithm (JWA) 仕様で定義されています。Red Hat Single Sign-On は、デフォルトパラメーター (RSA-OAEP) を使用して RSAES-PKCS1-v1_5 (RSA1_5) および RSAES OAEP をサポートします。このアルゴリズムを選択する詳細な手順は以下のとおりです。

CEK による ID トークン暗号化アルゴリズムは、JWA 仕様にも定義されます。Red Hat Single Sign-On は、128 ビットキー (A128GCM) を使用した AES_128_CBC_HMAC_SHA_256 認証暗号化 (A128CBC-HS256) および AES GCM に対応しています。このアルゴリズムを選択する詳細な手順は以下のとおりです。

クライアントの Settings タブでクライアントの access type を confidential に設定した場合は、新しい Credentials タブが表示されます。このようなクライアントの処理の一環として、クライアントのクレデンシャルを設定する必要があります。

Client Authenticator リストボックスは、機密クライアントに使用する認証情報のタイプを指定します。デフォルトはクライアント ID およびシークレットになります。シークレットは自動的に生成され、Regenerate Secret ボタンを使用すると、必要に応じてこのシークレットを再作成します。

または、シークレットではなく、署名済みの Json Web Token (JWT) または x509 証明書の検証 (別名 Mutual TLS) を使用することができます。

この認証情報タイプを選択すると、クライアントの秘密鍵と証明書も生成する必要があります。秘密鍵は JWT に署名するために使用されます。一方、証明書は、署名の検証にサーバーによって使用されます。Generate new keys and certificate ボタンをクリックして、このプロセスを開始します。

これらのキーを生成すると、Red Hat Single Sign-On は証明書を保存し、クライアントが使用する秘密鍵と証明書をダウンロードする必要があります。必要なアーカイブ形式を選択し、秘密鍵とストアのパスワードを指定します。

外部ツールを使用してこれらを生成したり、クライアントの証明書をインポートするだけです。

インポートできる形式は複数あります。証明書を保存するアーカイブ形式を選択し、ファイルを選択してから Import ボタンをクリックします。

最後に、JWKS URL の使用 を選択している場合は、証明書をインポートする必要はありません。このような場合には、クライアントが JWK 形式で公開鍵を公開する URL を指定できます。Red Hat Single Sign-On 側では、クライアントがキーを変更すると、Red Hat Single Sign-On 側ですべてのキーを再インポートする必要がないため、柔軟性があります。

Red Hat Single Sign-On アダプターで保護されたクライアントを使用している場合は、https://myhost.com/myapp がクライアントアプリケーションのルート URL であると仮定して、https://myhost.com/myapp/k_jwks のように JWKS の URL を設定することができます。詳細は『サーバー開発者ガイド』を参照してください。

このクライアントシークレットは、クライアントによって JWT に署名するために使用されます。

バリデーターは、証明書の Subject DN フィールドも、regexp 検証式を設定して確認します。いくつかのユースケースでは、すべての証明書を受け入れるだけで十分です。この場合は、(.*?)(?:$) 式を使用できます。

Red Hat Single Sign-On がリクエストからクライアント ID を取得する方法は 2 つあります。最初のオプションはクエリーの client_id パラメーターです (OAuth 2.0 仕様 のセクション 2.2 で説明されています)。2 つ目の方法として、client_id をフォームパラメーターとして指定します。

各 OIDC クライアントには、アクセストークンの取得を可能にする組み込み service account があります。これは、「クライアント認証情報の付与」の OAuth 2.0 仕様で説明されています。この機能を使用するには、クライアントの Access Type を confidential に設定する必要があります。これを実行すると、Service Accounts Enabled スイッチが表示されます。このスイッチをオンにする必要があります。また、クライアントのクレデンシャルを設定されていることを確認してください。

このクライアントを使用するには、有効な confidential Client を登録する必要があります。また、このクライアントでは、Red Hat Single Sign-On 管理コンソールでスイッチ Service Accounts Enabled を確認する必要があります。Service Account Roles タブは、このクライアントの代わりに取得したサービスアカウントで利用可能なロールを設定できます。Full Scope Allowed が許可されていない限り、このクライアントのロールスコープマッピング (Scope タブで利用可能なロールを持っている必要があることを覚えておいてください。通常のログインでは、アクセストークンからのロールは以下の交差部分になります。

呼び出す REST URL は /auth/realms/{realm-name}/protocol/openid-connect/token です。この URL の呼び出しは POST リクエストで、クライアントクレデンシャルを投稿する必要があります。デフォルトでは、クライアント認証情報は Authorization: Basic ヘッダーでクライアントの clientId および clientSecret によって表されますが、署名付きの JWT アサーションやその他のクライアント認証用のカスタムメカニズムを使ってクライアントを認証することもできます。OAuth2 仕様に従って、grant_type=client_credentials パラメーターを使用する必要があります。

たとえば、サービスアカウントを取得する POST 呼び出しは以下のようになります。

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

応答は、OAuth 2.0 仕様の標準の JSON ドキュメントです。

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}

デフォルトでは、アクセストークンのみが返されます。更新トークンが返されず、認証の成功時に Red Hat Single Sign-On 側でユーザーセッションも作成されません。更新トークンがないため、アクセストークンの期限が切れると再認証が必要ですが、セッションはデフォルトで作成されないため、Red Hat Single Sign-On サーバー側で追加のオーバーヘッドは保証されません。

このような状況では、ログアウトは必要ありません。ただし、発行されたアクセストークンは、「OpenID Connect Endpoints」セクションで説明するように、OAuth2 Revocation Endpoint にリクエストを送信して取り消すことができます。

Red Hat Single Sign-On がデプロイされる典型的な環境は、一般的に、認証に Red Hat Single Sign-On を使用する 秘密 または 公開 クライアントアプリケーション (フロントエンドクライアントアプリケーション) のセットで構成されています。

また、フロントエンドクライアントアプリケーションからの要求に対応し、リソースを提供する サービス (OAuth 2 仕様では Resource Servers と呼ばれる) もあります。これらのサービスは通常、特定のリクエストに対して認証を行うために、アクセストークン (Bearer トークン) を送信する必要があります。このトークンは、Red Hat Single Sign-On へのログインを試みる際に、フロントエンドアプリケーションによって取得されていました。

サービス間の信頼が低い環境では、以下のシナリオが発生する可能性があります。

このフローは、サービス間の信頼レベルの高い環境においては問題になる可能性があります。ただし、サービス間の信頼が低くなる他の環境では、この問題が発生する可能性があります。

上記の例にあるように、アクセストークンが誤用しないようにするため、トークンでオーディエンスを制限し、トークンに関するオーディエンスを検証するようにサービスを設定することを推奨します。これが実行されると、以下のように上のフローが変更されます。

クライアントが後で good-service を呼び出す場合は、scope=good-service で SSO ログインを発行し、別のトークンを取得する必要があります。返されるトークンには、対象として good-service が含まれます。

"audience": [ "good-service" ]

さらに、good-service を呼び出すことができます。