Hi, I'm probably missing something here, but what is the use case for allowing the plain transform method in PKCE? It seems to me the entire point of sending the hash of the code_verifier (code_challenge) rather than the code_verifier itself is to avoid leaking the code_verifier through the browser during the authorization request. It seems using the plain type would enable an attacker to intercept the code verifier and use it to exchange the code for the AT. If a client is really unable to compute a S256 hash, wouldn't it just fall back to vanilla OAuth?
Also, under security considerations, it mentions that if the code challenge is returned as part of the code, it needs to be encrypted. Not sure why since it was sent un-encrypted, where the attacker would have already had the opportunity to intercept/obtain it. Plus 7.3 re-enforces the point that the code verifier has sufficient entropy to prevent brute force attacks. I suppose the motivation then for encrypting the code_challenge is to address the scenario whereby 1) the plain transform method is used, and 2) a malicious app fails to intercept the code_challenge, but then 3) gets the code? Just looking for some background understanding of what went into these designs. tx! adam
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
