Aaron Parecki

@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

@aaronpk sorry I guess I should have specified "with https". doesn't https' security model encompass this one?

@aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?

@aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?

@aaronpk This is a good post! But I'm having trouble trying to understand the attack that the authorization flow is protecting against. How can a token be stolen "in transit back to the application"?