2

i am reading this in the OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

What is the difference between a client_id and a distinguished name? I see in the PKI Mutual-TLS Method that the distinguished name of the client is registered into the auth server. What is the purpose of the client_id?

Also what exactly the meaning of the metadata? For example, the following is an action of the client to inform the server about the distinguished name or is the way that the auth server registers the distinguished name?

 tls_client_auth_subject_dn
      A string representation -- as defined in [RFC4514] -- of the
      expected subject distinguished name of the certificate that the
      OAuth client will use in mutual-TLS authentication.
Community
  • 1
loutsi1
  • 41
  • 7

1 Answers1

3

Client Identifier

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.

Distinguished Name

The distinguished name is part of the X.509 PKI Certificate Specification:

4.1.2.4. Issuer
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.
4.1.2.6. Subject
[...] 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 that client.

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 client.

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 respective client.

Community
  • 1
katexochen
  • 303
  • 1
  • 8
  • how the client transmits the client_id to the AS.? The authentication is performed by exchange certificates. There is not filed in x.509 v3 certificate in order for the client to convey the client_id. Neither in the client hello message during the handshake procedure – loutsi1 Jan 28 '21 at 13:04
  • @loutsi1 During the registration, the client_id is created by the AS and sent to the client. This happens once per client. The certificate is used later, during the authentication, everytime the client needs to authenticate at the AS. I'll try to add a image with the protocol flow soon. – katexochen Jan 29 '21 at 09:13
  • yes I understand this. What I am asking is the following. How the client sends the issued id to ΑS? For each communication, the client must send the issued client iD to ΑS. The latter then can check the cliend_id that the client sends with the client_id value that has stored in his database. And in the case that the value of them do not match the AS prevent the communication. In which part of the communications between them does this happen – loutsi1 Jan 29 '21 at 09:22
  • As handshake protocol is the way that two parts can communicate the cliend_id should be sent with the client hello message. But this not happen – loutsi1 Jan 29 '21 at 09:24
  • @loutsi1 The client and the AS build up an TLS Channel, using a client_certificate. The client_id and other infromation are send as in normal OAuth, but **over the established TLS connection**. So there is no client_id sent in the TLS Handshake. – katexochen Jan 29 '21 at 12:40
  • are you able to suggest me a source of information in order to see how client_id is sent in normal OAuth? – loutsi1 Jan 29 '21 at 13:36
  • @loutsi1 There is no example in the RFC, but you can finde a samle token request [here](https://docs.akana.com/cm/api_oauth/oauth_oauth20/m_oauth20_getTokenPOST.htm#samplerequest) – katexochen Jan 29 '21 at 13:53
  • ok thank you very much. My confusion was that I thought that even for mutual tls authentication the client had to send the client_id to the server and if the client_id was not that was anticipated from the server the latter did not allow the communication. However, your answer suggests that is sent after mutual tls authentication in order for the client to ask for token. – loutsi1 Jan 29 '21 at 14:06