!!! Overview 
[{$pagename}] defined in [Mutual TLS Profiles for OAuth Clients] and defines how the [Authorization Server] is able to bind the issued [Access Token] to the [OAuth Client] [certificate].  Such a binding is accomplished by associating the [certificate] with the [Access Token] in a way that can be accessed by the [Protected Resource], such as embedding the [certificate] [hash] in the issued [Access Token] directly, using the syntax described in [Mutual TLS Profiles for OAuth Clients] Section 3.1, or through token introspection as described in [Mutual TLS Profiles for OAuth Clients] Section 3.2.  

Other methods of associating a certificate with an access token are possible, per agreement by the authorization server and the protected resource, but are beyond the scope of [Mutual TLS Profiles for OAuth Clients].

The client makes [Protected Resource] requests as described in [RFC 6750], however, those requests [MUST] be made over a [Mutual Authentication] [TLS] connection using the same certificate that was used for mutual [TLS] at the [token_endpoint].

The [Protected Resource] [MUST] obtain the client [certificate] used for mutual [TLS] authentication and [MUST] [verify that the certificate|Certificate Validation] matches the [certificate] associated with the [Access Token].  

If they do not match, the resource access attempt [MUST] be rejected with an [OAuth Error] per [RFC 6750] using an [HTTP 401] [status code|HTTP Status Code] and the "[invalid_token]" error code.

[Metadata] to convey server and client capabilities for mutual [TLS] sender constrained access tokens is defined in Section 3.3 and Section 3.4 respectively.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]