Mutual TLS

Clients can authenticate to AM through mutual TLS (mTLS) and X.509 certificates. Certificates must be self-signed or use public key infrastructure (PKI), as described in version 12 of the draft OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens.

For a client using mTLS, its OAuth 2.0 profile includes a means to access its certificate. When the client requests an access token from AM with mTLS, it authenticates with its certificate to establish the HTTPS connection. This is known as mutual authentication—​because the server and client authenticate each other—​or client certificate authentication. The client proves it has the private key for the certificate.

The authorization server (AS), such as AM, binds the access token to the client certificate with a confirmation key. The confirmation key is a certificate thumbprint, computed as base64url-encode(sha256(der(certificate))). The access token is then certificate-bound, restricted to the client having the corresponding private key. The confirmation key is not necessarily visible in the access token, but the AS provides it on token introspection.

A resource server (RS), such as PingGateway, has the client use HTTPS mutual authentication when requesting a resource with the certificate-bound access token. The RS gets the certificate and proves the client has its private key when setting up HTTPS. The RS gets the confirmation key for the access token and verifies the certificate matches the key. The RS only grants access when the certificate matches the confirmation key.

This proof-of-possession interaction ensures only the client with the private key for the certificate can use the token to access protected resources.