Why Both PKCE and Client-Secret

Question

I am new to OAuth (and Okta).

My understanding is that PKCE essentially makes a client secret unnecessary. I understand that PKCE is needed for public clients (which is what I am working with). Okta configuration, however, allows for both PKCE and a Client Secret simultaneously (see the attached image).

Why would I want both? If I am using a client secret, why bother with PKCE? Since I am working with a public client I do not want to have to use a public secret.

Doesn't PKCE obviate the need for a Client Secret?

---

Answer 1

PKCE is generally meant for public clients. However, secret clients can still benefit from it as an additional layer of security. When a confidential makes a token request to exchange the authorization code for an access token, it has to prove that it is the legitimate client to whom this token was issued by providing its client secret, which is supposed to be only known to itself and the authorization server.

When a public client using PKCE goes through the same process, it generates dynamic credentials (in plain English, it generates a secure random string on the fly) upon making the authorization request and then hashes it and only sends the hash value with the request. Upon exchanging the authorization code for an access token, the public client has to provide the original value (whose hash was sent) to prove that it is the client that made the authorization request. PKCE is not proof of being a legitimate client, it is only proof of being the client that initiated the OAuth flow. So while PKCE does improve the security of public clients, it doesn't offer the same level of security given by a static credential (client secret).

So why does Okta allow both together? Because confidential clients can use it to harden their security at a very trivial cost. Generating a random string, hashing, and verifying it is trivial both from an implementation as well as performance perspective.

Take this hypothetical scenario: Suppose a confidential client doesn't implement PKCE. In this case, the administrator of the server hosting the client could potentially intercept the authorization code, perhaps from the Nginx log, and then exchange it for an access token. This is possible because the administrator might also have access to the client secret, which could be stored in a configuration file or an environment variable. However, with PKCE in place, this risk is mitigated. Even if the administrator intercepts the authorization code, they won't be able to exchange it for an access token, as they cannot demonstrate that they initiated the original authorization request as the code verifier was never revealed to them, only its hash value which they cannot feasibly reverse compute within the lifetime of the authorization code (usually seconds to max. minutes).