PKCE: Surely hacker can still steal access token?

Question

From my understanding, the advantage that Authorization Code Flow has over Implicit Flow is that with ACF, the access token gets sent to a server side app rather than to a browser app. This makes the access token much harder to steal, because the access token never reaches the browser (and is thus not susceptible to a Cross Site Scripting attack).

I would have thought that PKCE would try to solve this issue. But it does not. The access token is still sent to the browser. Hence it can still be stolen.

Is there something I am missing here? Many thanks.

Carminacarminative

Answer 1

Authorization Code Flow (PKCE) is considered superior security to the previous solution of Implicit Flow:

• With implicit flow the access token was returned directly in a browser URL and could perhaps be viewed in logs or the browser history

With Authorization Code Flow this is handled better, with reduced scope for exploits:

• Phase 1: A browser redirect that returns a one time use 'authorization code'
• Phase 2: Swapping the code for tokens is then done via a direct Ajax request

PKCE also provides protection against a malicious party intercepting the authorization code from the browser response and being able to swap it for tokens.

Both are client side flows and their reason for existing is to use access tokens in public clients. Authorization Code Flow (PKCE) is the standard flow for all of these:

• Single Page Apps
• Mobile Apps
• Desktop Apps

In the SPA case the token should not be easily stealable, especially if stored only in memory as recommended. However, there are more concerns when using tokens in a browser, since it is a dangerous place, and you need to follow SPA Best Practices.

In the browser case there are other options of course, such as routing requests via a web back end or reverse proxy in order to keep tokens out of the browser, and dealing with auth cookies in addition to using tokens.

Komatik

Thanks, the key part of your answer that helped was the first bullet point. I now understand that it is not that easy to steal tokens from the browser, its only easy to steal them from the browser URL history. – Carminacarminative

I saw a video youtube.com/watch?v=996OiexHze0 at 26"42', the guy answered Swapping the code for tokens is then done via back channel. But you mentioned in phase 2, Swapping the code for tokens is then done via a direct Ajax request. Are they same thing? – Eolanda

Answer 2

I think your are right. The tokens are not in a http-only cookie, and are therefore accessible by a malicious script (injected via an XSS attack). The attacking script can read all tokens (after a successful and normal auth flow) from local storage (or wherever they got put) and use them.

I think CORS protections should prevent the malicious script from sending the tokens out to an attacker directly, which would be a devastating failure, as this potentially includes a long lived refresh token. Therefore, I suspect configuring CORS correctly is super critical when using these local-client based flows (by local-client I mean a browser, mobile app, or native PC app).

In short, these local-client flows can be made secure, but if there is an XSS attack, or badly configured CORS, then those attacks can become extremely dangerous - because the refresh token could potentially be sent to the attacker for them to use at will in their own good time, which is about as bad as an attack can get.

Prerequisite

CORS doesn't protect against XSS, as the malicious agent can simply send the access token to their server and make requests from that location, where CORS is no longer relevant in that context. – Cottonmouth