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 クライアント認証」サポートの有効化と、クライアントの「サブジェクト名」の登録が必要です。

サービス側の TLS クライアント認証設定
Authlete のサービス管理者コンソールにログインし、 「認可」タブの「トークンエンドポイント」セクションにおいて以下を設定します。
タブ |
項目 |
値 |
認可 |
サポートするクライアント認証方式 |
TLS_CLIENT_AUTH |

クライアント側の TLS クライアント認証設定
Authlete のクライアントアプリ開発者コンソールにアクセスし、 「認可」タブの「トークンエンドポイント」セクションにおいて以下を設定します。
タブ |
項目 |
値 |
認可 |
サポートするクライアント認証方式 |
TLS_CLIENT_AUTH |
認可 |
Subject Distinguished Name |
(例: CN=client.example.org, O=Client, L=Chiyoda-ku, ST=Tokyo, C=JP) |
以上の設定により、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 がお話しします。
How did we do with this article?