Aaron Parecki

@aaronpk you linked to "Insufficient Redirect URI Validation" though? maybe i'm just confused about what you were talking about.

@aaronpk Yes, i get that, but the attacker can make the access token request just as easily as the legitimate client.

@aaronpk no, I understand that one, I just still don't see how pkce helps improper redirect validation (since the pkce secret and redirect URI come from the same request)

@aaronpk huh? But the redirect_uri is controlled by the same person who controls the code_challenge

@aaronpk isn't the section you linked to just as much of a concern under the authorization code flow as the implicit flow? since javascript clients are public clients no matter what?

@aaronpk This could save you 4 characters ;))
return btoa(encodeURIComponent(str)
.replace(/%([0-9A-F]{2})/g, (m, p1) => String.fromCharCode(parseInt(('0x'+p1), 16))));

@aaronpk sure, but a malicious browser could also save the entire js state to disk in exactly the same way (and some do a limited version of this for caching purposes). so it's hard for me to think of that as a security benefit? this is only more secure if everyone along the line behaves exactly in the way you expect it to

@aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better

@aaronpk but the browser is also the one executing the code that's verifying whether the browser transferred the data correctly? maybe a concrete attack would help me get my head around this better