はじめに
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 のクライアントアプリ開発者コンソールにアクセスし、 「認可」タブの「トークンエンドポイント」セクションにおいて以下を設定します。本例では「サブジェクト名」の種類として 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 接続を確立した後にクライアントからトークンリクエストを受け取った認可サーバーが、Authlete の /auth/token API に送信するリクエストの例です（一部折り返しています）。 “parameters” パラメーターの値として、トークンリクエストの内容（この中にクライアント ID (client_id) を含む）を指定しています。また “clientCertificate” パラメーターの値としてクライアント証明書を指定しています。関連情報
本記事では、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 がお話しします。