OAuth2 public clients cant use client secret and still achieve a secure workflow, why is it used for confidential clients?

Question

In an OAuth2 authorization flow, if I understand correctly the request made to receive a token with PCKE is almost identical between that of a public client and that of a confidential client. The only real difference is that a confidential client will also send along the "client secret" while a public client does not because that would make the secret available to the public.

If a public client does not send the client secret, but can still seemingly obtain a token in a secure fashion, than what is the purpose of sending the client secret in a confidential client situation? I get that it guarantees the client is legit but does that mean by being unable to include it from a public client that there is some loophole in security in this approach and the community is fine with that?

Answer 1

You are explaining two separate types of applications. The difference being the exposure of the client secret.

A confidential client is just a client that is preforming the authentication secretly, without any public access if you do not have the secret key. The one preforming the authentication is secret, not known to the public, not on a public website or mobile application.

A public client will sill preform the authentication the same way using the same secret, the different being that this time it is stored client side publicly such as on a public mobile application or public website.

So yes, if an application was using the same authentication process for public and confidential clients to grant the same permissions - this would be an issue. But this is usually not the case, a application nature would describe if it is public or confidential.

Source: RFC 6749 Section 2.1

Answer 2

If a public client does not send the client secret, but can still seemingly obtain a token in a secure fashion, than what is the purpose of sending the client secret in a confidential client situation?

The main purpose of the client_secret was to identify the client and to ensure that the token request come from the client for which the code was generated. The problem is that new types of attacks (authorization code interceptions and authorization code injection) have been identified, which caused that client_secret is not enough to ensure that code is bound to the client. That is why PKCE and nonce (for OpenIDConnect) were presented.

This might look like the client_secret is unnecesary but you have to remember that:

1. client_secret was from the very beginning in OAuth2 / OpenIDConnect standards,
2. you should implement Security in Depth principle where ever you can

In my opinion, if you can use additional level of security control, you should use it.