Is OAuth2.0 Authorization Code Grant flow with PKCE really secure?

Question

CONTEXT

There is a SPA that uses Authorization Code Grant flow with PKCE to get info from an API all the info is highly sensitive

RESEARCH

Here is what I found of how Authorization Code Grant flow with PKCE works:

THE FLOW

v = code_verifier

$ = code_challenge

a = authorization_code

THE PURPOSE

In this article https://www.scottbrady91.com/oauth/client-authentication-vs-pkce said that PKCE is not enough and you need client authentication still

PKCE helps protect you against various code injection attacks, but PKCE does not replace client authentication.

and the purpose of PKCE is to ensure that all the requests come from the same client

With PKCE, you prove that the same application is swapping the code as the one who requested it.

WHAT I UNDERSTOOD

PKCE is just to ensure that all the requests come from the same client, but it doesn't care if the client is authorized or not

REMEMBER:

• The SPA can't use the backend, so all requests are exposed all the time

• I can't rely on SOP or CORS to block, you know that some clients like postman can overpass SOP and CORS

• The info is very sensitive, so only authorized clients can get the info, for example: https://authorized-third-party.com must be able to get his info, but http://fake-third-party.com must not be able to get the info

QUESTIONS

• What will happen if someone authenticates using the SPA and get code_verifier (random string), code_challenge (hashed code verifier using SHA-256) and authorization code (or simply the token generated at the end of the grant flow) from the request by opening the web developer tools, Is he able to request the information in its own client using verifier, challenge and auth code to get the information?

• What is the real purpose of Authorization Code Grant flow with PKCE?

• Should include any additional grant flow? If so, which and how can I combine both?

• if PKCE purpose is not caring if the client is authorized or not, How can avoid unauthorized clients to get the info?

Answer 1

This might be a bit old, so just adding it here to help others.

If you look at the auth code flow without pkce, you'll see the need for the client secrets and the attack vector it aims to solve. So, for the PKCE flow (originally intended for mobile apps and now also SPA's), since it's assumed that the client can't hold a secret safe enough, the code verifier aims to solve that problem from a high level perspective. Essentially, a secret generated, like the client_secret but not fixed, per auth request and the server is entrusted in verifying the sha256 hash with the original value, because the client doesn't trust itself.

For this,

PKCE helps protect you against various code injection attacks, but PKCE does not replace client authentication.

You're missing the context from the website, which is the answer to the question “Do I still need a client secret when using PKCE?” which is "Yes, assuming you can keep a secret."

To sort of make it clear, there is no PKCE on its own. Its auth code with PKCE extension (https://oauth.net/2/pkce/) and if people refer to PKCE alone, at least the people i've encountered, they mean auth code flow with pkce.

So essentially here, PKCE's original "scope" of addressing the native apps has increased to server side in ensuring the calling application is the one in control and enforce the defence in depth concept.

Answers to your questions:

1. The scenario you mention is that essentially if look at the oauth flow and see the data. This isn't really any different that if someone can use developer tools to look at the POST of the login containing username and password. If an attacker has that level of control, there's nothing that oauth or passwords can do at that time.

2. There are now multiple purposes of auth code flow with PKCE. Using with SPA's and Mobile apps as originally intended. Now use can use it on server side as well, to ensure that no other apps on the server, other that the specific app and app alone, is able to exchange the code for an access token.

3. These flows have been threat modeled, analyzed and studied in detail for a lot of people to understand exactly the scenario's it protects and where it falls short. "Combining" flows doesn't increase security like 1+1=2 would. If you do end up with a new flow, you will have to do the same steps of understanding the threats, model your apps and see what the issues are and as always, don't roll out your own, if you don't know what entails from that process.

4. Check answers 1 and 2.

Hope this helps.