The client identifier (client_id) is a string chosen by the authorization server (AS) during the client registration, as defined in the OAuth 2.0 RFC.
2.2. Client Identifier
The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client. The client identifier is not a
secret [...] The client identifier is unique to
the authorization server.
If the client wants to authenticate at the AS, the client uses his client_id to tell the AS which specific client is going to communicate with him.
The distinguished name is part of the X.509 PKI Certificate Specification:
The issuer field identifies the entity that has signed and issued the
certificate. The issuer field MUST contain a non-empty distinguished
name (DN). [...] distinguished names are composed of attributes.
[...] the subject field MUST contain an X.500
distinguished name (DN). The DN MUST be unique for each subject
entity certified by the one CA as defined by the issuer field.
So the issuer of a X.509 certificate writes his distinguished name inside the certificates he issues, as well as the distinguished name of the subject he issues a certificate for. A DN consists of multiple elements, e.g. country and organisation. For StackExchanges certificate, the issuers DN consists of US and Let's Encrypt, while the subjects DN consist of multiple Subject Alt Names, that are DNS names.
PKI Methode of mTLS OAuth 2.0 Client Authentication
In OAuth mTLS, the AS uses the client_id to look up the clients configuration and expected credential, as explained in Section 2:
For all requests to the authorization server utilizing mutual-TLS
client authentication, the client MUST include the "client_id"
parameter [...] the "client_id" parameter enables the authorization
server to easily identify the client independently from the content
of the certificate. 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
In contrast to the Self-Signed Certificate Method of authenticating the client, the distinguished name is only used in the PKI Methode, where it is used to identify the client in a verified way:
PKI Mutual-TLS Method relies on a validated
certificate chain [RFC5280] and a single subject distinguished name
(DN) or a single subject alternative name (SAN) to authenticate the
During the OAuth Dynamic Client Registration, a client registrates at the AS. During this process, the client sends metadata, that is stored by the AS and later used during the client authentication. So the
tls_client_auth_subject_dn is an information, a string, the client sends to the AS during registration. It is thus not an action. It is the piece of information the AS will use at a later attempt of the client to authenticate to identify the X.509 certificate and to verify the certificate belongs to the client, as written in Section 2.1.2:
A client using the [...] MUST use exactly one of the
[...] metadata parameters to indicate the certificate subject value
that the authorization server is to expect when authenticating the