3

A typical OAuth2 Authorization Code Flow scenario looks like this:

Typical flow diagram

What I'm not understanding is the purpose of the client secret in steps 6 and 7. If the auth server is guaranteed to redirect back to the web app and send its authorization code there, how could an attacker get the authorization code (which is presumably the reason for the client secret)?

In addition, it seems that the PKCE extension does away with the need for the client secret, but reading the RFC for that I can't see any reason why it should. Could somebody explain this for me?

Community
  • 1
Jez
  • 275
  • 1
  • 11

2 Answers2

3

In the context of an authorization code grant, the main purpose of the client secret is to prevent client impersonation. That is to say, it prevents a malicious client from pretending to be a legitimate client in order to get an access token from the resource owner under false pretenses.

It is worth pointing out that using a client secret is not the only means available to prevent client impersonation. For public clients (such as mobile apps and single page apps), client impersonation is prevented by the use of fixed https redirect uris. By only allowing specific, https redirect uris, a malicious client attempting to act as a legitimate client would be unable to intercept the authorization code. By being unable to intercept the authorization code, the malicious client would be unable to make the request to the token endpoint.

PKCE solves a different problem - basically, it prevents a malicious client that has somehow received an authorization code from using it to request an access token from the token endpoint. This was originally recognized as a problem in the mobile app space, but it is a useful technique for single page apps too. There is actually no harm in using PKCE with every OAuth 2 client, even those which use a client secret. The OAuth 2 Best Current Practice recommends using it everywhere.

Jake Feasel
  • 231
  • 1
  • 3
  • Could you give an example of where you wouldn't use a fixed https redirect URI? I thought it was always fixed. – Jez Feb 05 '20 at 22:37
  • 1
    The OAuth 2 BCP gives a good example: [Redirect URI Validation Attacks on Authorization Code Grant](https://tools.ietf.org/id/draft-ietf-oauth-security-topics-13.html#insufficient_uri_validation_acg) – Jake Feasel Feb 06 '20 at 01:36
1

"What is the purpose of the OAuth2 client secret?"

As described in the oauth.com documentation, the client_secret can be considered as a password that is known only by the client itself and the authorization server. That's basically it, it's a password used to authenticate the "Regular Web App" on the "Auth0 Tenant".

The client_secret is a secret known only to the application and the authorization server.

The important part here is to not get confused about the user password, and the client_secret, that are different secrets, and are used in different parts of the OAuth 2.0 flow.

tl;dr: client_secret = Regular Web App's password. client_id = Regular Web App's user name.

Filipe dos Santos
  • 1,090
  • 4
  • 15
  • 1
    But a "public" client, as opposed to a "confidential" one, doesn't have to pass a client ID and secret. So what's the point? – Jez Feb 05 '20 at 18:49
  • I'm not sure what do you mean by public and confidential clients. For the Authorization Code Flow, the client is supposed to always present a client_id (user name) and client_secret (password) in order to authenticate in the Authorization Server. Do you have any working examples without a client_secret? – Filipe dos Santos Feb 05 '20 at 18:52
  • A client secret is not required for the authorization code flow. PKCE was designed specifically for this scenario. – Jake Feasel Feb 05 '20 at 20:44
  • [Auth0 does require a client_secret for the authorization code flow](https://auth0.com/docs/flows/guides/auth-code/call-api-auth-code#request-tokens). – Filipe dos Santos Feb 05 '20 at 20:47
  • Auth0's implementation is not all of OAuth 2. See the section in the spec regarding the [Access Token Request](https://tools.ietf.org/html/rfc6749#section-4.1.3): "*If* the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1." Note the *if*. Client authentication is not required for the auth code grant. – Jake Feasel Feb 05 '20 at 21:31
  • 1
    Regarding the difference between a public client and a confidential one, see the spec: [Client Types](https://tools.ietf.org/html/rfc6749#section-2.1) – Jake Feasel Feb 05 '20 at 21:32