Hacker News Reader

Comment by smallnix | Hacker News Reader

In oauth2: when I /1 associate a random uuidv4 for each new flow with my user (server side), /2 stick that uuid into the state parameter, and then /3 look up my user with this on callback-endpoint execution. Isn't PKCE in that case redundant?

View on HN

Oauth's PKCE verifies the continuity of the flow as it is essentially a saga(multi-step process). For example you can initiate oauth access grant request multiple times with the same data, but PKCE ensures that each of those initiations can be individually identified. Do not confuse PKCE with state field, which is for XSS and has no obfuscation.

Just to be clear, the PKCE secret can be the same for each initiation, but in the end its goal is to ensure that the first request matches with the last one. And yes, there is "plain" PKCE method but that is just for testing. SHA256 is the default one used to obfuscate the secret.

I think one point of PKCE is that the oauth token is never sent to the client (it is exchanged on the backchannel), so it theoretically is more protected.

Of course if you trust the client (no bad browser extensions, updated browser) and have good TLS settings and no MITM risk and make sure the your IDs are single-use then it seems like that should be fine.

PKCE protects the auth token from interception by making it so that only your code that started the flow can redeem it by proving they have the secret code_verifier on the redeem_token() call.

The code_challenge == sha256(code_verifier). You will share the code_challenge at the start of the flow.

I also think these are very similar. The main difference in my view is that the state parameter is checked by the client, while PKCE is checked by the server.

I run an authentication server and requiring PKCE allows me to make sure that XSS protection is handled for all clients.

If you can, switch to uuid v7 if you're indexing by that id. Performance improvement while still not being sequential IDs.

For this sort of use-case v4 might be better. It has more randomness and you will probably delete the old ids as soon as they are used anyway, so the indexed space will probably be small.

How small is small, and how often is that state checked?

I guess it's probably not tracking tons of IDs like tracking packet state through a network device.

Even a few million (max) UUIDv4 is probably fine then, yeah?

Yeah, I'd say that sounds fine. Since these are supposed to be used within a short time it'd also be easy to cleanup unused ones more then 5mins old or so.

Reply on news.ycombinator.com