1. Introduction

This document describes an additional mechanism of client authentication utilizing mutual-TLS certificate-based authentication that provides better security characteristics than shared secrets.

Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources.

Binding an access token to the client's certificate prevents the use of stolen access tokens or replay of access tokens by unauthorized parties.

Mutual-TLS certificate-bound access tokens and mutual-TLS client authentication are distinct mechanisms that are complementary but don't necessarily need to be deployed or used together.

1.2 Terminology

Throughout this document the term "mutual TLS" refers to the process whereby, in addition to the normal TLS server authentication with a certificate, a client presents its X.509 certificate and proves possession of the corresponding private key to a server when negotiating a TLS session.

2. Mutual TLS for OAuth Client Authentication

For all requests to the authorization server utilizing mutual-TLS client authentication, the client include the client_id parameter

In order to utilize TLS for OAuth client authentication, the TLS connection between the client and the authorization server have been established or re-established with mutual-TLS X.509 certificate authentication (i.e., the client Certificate and CertificateVerify messages are sent during the TLS handshake).

The authorization server can locate the client configuration using the client identifier and check the certificate presented in the TLS handshake against the expected credentials for that client

2.1. PKI Mutual-TLS Method

It relies on a validated certificate chain and a single subject distinguished name (DN) or a single subject alternative name (SAN) to authenticate the client. Only one subject name value of any type is used for each client

The TLS handshake is utilized to validate the client's possession of the private key corresponding to the public key in the certificate and to validate the corresponding certificate chain. The client is successfully authenticated if the subject information in the certificate matches the single expected subject configured or registered for that particular client

2.1.1 PKI Method Metadata Value

Adds the tls_client_auth HTTP Parameter.

2.1.2 Client Registration Metadata

A client using the tlsclientauth authentication method use exactly one of the below metadata parameters to indicate the certificate subject value that the authorization server is to expect when authenticating the respective client.

During client registration:

tls_client_auth_subject_dn : Subject distinguished name of the certificate

tls_client_auth_san_dns: dNSName SAN entry in the certificate

tls_client_auth_san_uri: uniformResourceIdentifier SAN entry in the certificate

tls_client_auth_san_ip: IP addres, either IPv4 or IPv6 y in the certificate

tls_client_auth_san_email: rfc822Name SAN entry in the certificate

2.2. Self-Signed Certificate Mutual-TLS Method