Transport Layer Security (TLS) is used to establish a secure communication channel between two applications, typically a client browser and web server. Mutual TLS extends this by providing strong identification of the client through a client certificate. When used in an ONTAP cluster with OAuth 2.0, the base mTLS functionality is extended by creating and using sender-constrained access tokens.

A sender-constrained access token can only be used by the client to which it was originally issued. To support this feature, a new confirmation claim (cnf) is inserted into the token. The field contains property x5t#S256 which holds a digest of the client certificate used when requesting the access token. This value is verified by ONTAP as part of validating the token. Access tokens issued by authorization servers that are not sender-constrained do not include the additional confirmation claim.

You need to configure ONTAP to use mTLS separately for each authorization server. For example, the CLI command security oauth2 client includes the parameter use-mutual-tls to control mTLS processing based on three values as shown in the table below.

The typical steps involved when using mTLS with OAuth 2.0 in an ONTAP environment are presented below. See RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens for more details.

Establishing client identity is based on proving knowledge of a client private key. The corresponding public key is placed in a signed X.509 certificate presented by the client. At a high level, the steps involved in creating the client certificate include:

You can normally install the client certificate in your local operating system or use it directly with a common utility such as curl.

You need to configure ONTAP to use mTLS. This configuration is done separately for each authorization server. For example, with the CLI the command security oauth2 client is used with the optional parameter use-mutual-tls. See Deploy OAuth 2.0 in ONTAP for more information.

The client needs to request an access token from the authorization server configured to ONTAP. The client application must use mTLS with the certificate created and installed in step 1.

The authorization server verifies the client request and generates an access token. As part of this, it creates a message digest of the client certificate which is included in the token as a confirmation claim (field cnf).

The client application makes a REST API call to the ONTAP cluster and includes the access token in the authorization request header as a bearer token. The client must use mTLS with the same certificate used to request the access token.

ONTAP receives the access token in an HTTP request as well as the client certificate used as part of mTLS processing. ONTAP first validates the signature in the access token. Based on the configuration, ONTAP generates a message digest of the client certificate and compares it to the confirmation claim cnf in the token. If the two values match, ONTAP has confirmed the client making the API request is the same client the access token was originally issued to.