tls_client_auth によるクライアント認証

tls_client_auth によるクライアント認証

はじめに

RFC 8705 の “2. Mutual TLS for OAuth Client Authentication” では、認可サーバーが相互 TLS 接続を用いてクライアントを認証するしくみ (tls_client_auth) が仕様化されています。

本記事では、クライアント認証に tls_client_auth を用いるための、サービスおよびクライアントの設定について説明します。

Authlete における TLS クライアント認証のしくみ

Authlete の TLS クライアント認証は、クライアントの ID と、クライアント証明書に含まれる「サブジェクト名 」(サブジェクト識別名・サブジェクト代替名)を用いて行います。

認可サーバーはこれらに相当する情報として、「クライアント ID」と「クライアント証明書」(クライアントの「サブジェクト名」が含まれている)を、トークンリクエスト処理を依頼する(/auth/token API を呼び出す)際に、トークンリクエストの内容と併せて送信します。

このうち「クライアント ID」は、トークンリクエストの内容に含まれています。もう一方の「クライアント証明書」については、認可サーバーはクライアントと相互 TLS 接続を確立して取得する必要があります。

この Authlete の機能を用いるには、「TLS クライアント認証」サポートの有効化と、クライアントの「サブジェクト名」の登録が必要です。

mtls-client-authentication_ja

サービス側の TLS クライアント認証設定

Authlete のサービス管理者コンソールにログインし、 「認可」タブの「トークンエンドポイント」セクションにおいて以下を設定します。

タブ 項目
認可 サポートするクライアント認証方式 TLS_CLIENT_AUTH
tls-client-auth_1
認可 タブ

クライアント側の TLS クライアント認証設定

Authlete のクライアントアプリ開発者コンソールにアクセスし、 「認可」タブの「トークンエンドポイント」セクションにおいて以下を設定します。

本例では「サブジェクト名」の種類として Subject Distinguished Name (Subject DN) を用いていますが、Authlete は Subject  DN 以外にも各種 Subject Alternative Name (SAN) をサポートします。

タブ 項目
認可 サポートするクライアント認証方式 TLS_CLIENT_AUTH
認可 Subject Distinguished Name (例: CN=client.example.org, O=Client, L=Chiyoda-ku, ST=Tokyo, C=JP)
tls-client-auth_2
認可 タブ

以上の設定により、Authlete サービスは TLS 双方向認証によるクライアント認証に対応し、かつ上記のクライアントからのトークンリクエストについて、その認証方式を適用することになります。 また認証の際のサブジェクト識別名として CN=client.example.org, … を用います。

動作例

以下は、相互 TLS 接続を確立した後にクライアントからトークンリクエストを受け取った認可サーバーが、Authlete の /auth/token API に送信するリクエストの例です(一部折り返しています)。

“parameters” パラメーターの値として、トークンリクエストの内容(この中にクライアント ID (client_id) を含む)を指定しています。また “clientCertificate” パラメーターの値としてクライアント証明書を指定しています。

curl -s -X POST https://api.authlete.test/api/auth/token \
-u '174381609020:LszYEVDLM5Bu4lRjO9Vaj0tMSMVerWiPf_zcdy-vu4k' \
-H 'Content-Type: application/json' \
-d '{
"parameters": "grant_type=authorization_code&
 redirect_uri=https://client.example.org/cb/example.com&
 client_id=591205987816490
 &code=HVIza0dGG9nDKGStAzMObYH9GkXME0aRSaLEcToHEI8",
"clientCertificate":"-----BEGIN CERTIFICATE-----
MIIDPDCCAiQCCQDWNMOIuzwDfzANBgkqhkiG9w0BAQUFADBgMQswCQYDVQQGEwJK
UDEOMAwGA1UECAwFVG9reW8xEzARBgNVBAcMCkNoaXlvZGEta3UxDzANBgNVBAoM
BkNsaWVudDEbMBkGA1UEAwwSY2xpZW50LmV4YW1wbGUub3JnMB4XDTE5MTAyODA3
MjczMFoXDTIwMTAyNzA3MjczMFowYDELMAkGA1UEBhMCSlAxDjAMBgNVBAgMBVRv
a3lvMRMwEQYDVQQHDApDaGl5b2RhLWt1MQ8wDQYDVQQKDAZDbGllbnQxGzAZBgNV
BAMMEmNsaWVudC5leGFtcGxlLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAK2Oyc+BV4N5pYcp47opUwsb2NaJq4X+d5Itq8whpFlZ9uCCHzF5TWSF
XrpYscOp95veGPF42eT1grfxYyvjFotE76caHhBLCkIbBh6Vf222IGMwwBbSZfO9
J3eURtEADBvsZ117HkPVdjYqvt3Pr4RxdR12zG1TcBAoTLGchyr8nBqRADFhUTCL
msYaz1ADiQ/xbJN7VUNQpKhzRWHCdYS03HpbGjYCtAbl9dJnH2EepNF0emGiSPFq
df6taToyCr7oZjM7ufmKPjiiEDbeSYTf6kbPNmmjtoPNNLeejHjP9p0IYx7l0Gkj
mx4kSMLp4vSDftrFgGfcxzaMmKBsosMCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEA
qzdDYbntFLPBlbwAQlpwIjvmvwzvkQt6qgZ9Y0oMAf7pxq3i9q7W1bDol0UF4pIM
z3urEJCHO8w18JRlfOnOENkcLLLntrjOUXuNkaCDLrnv8pnp0yeTQHkSpsyMtJi9
R6r6JT9V57EJ/pWQBgKlN6qMiBkIvX7U2hEMmhZ00h/E5xMmiKbySBiJV9fBzDRf
mAy1p9YEgLsEMLnGjKHTok+hd0BLvcmXVejdUsKCg84F0zqtXEDXLCiKcpXCeeWv
lmmXxC5PH/GEMkSPiGSR7+b1i0sSotsq+M3hbdwabpJ6nQLLbKkFSGcsQ87yL+gr
So6zun26vAUJTu1o9CIjxw==
-----END CERTIFICATE-----"}'

関連情報

本記事では、Authlete のクライアント認証設定の基本を説明します。

本記事では、“RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens” にて規定されている “Mutual-TLS certificate-bound access tokens” を利用するための、Authlete の設定手順を説明します。

このビデオは、2018 年 7 月 24 日に開催された Financial APIs Workshop 2018 のプレゼンテーション録画のひとつです。 OAuth 基盤構築における従来のアプローチと Authlete 独自の Semi-hosted アプローチとの比較、Authlete が FAPI を実装するにあたってどのようにクライアント認証機能の拡張や双方向 TLS の対応を行なったかについて、 Authlete の Justin Richer がお話しします。