OAuth Happy Hour - Authorization Code Injection Demo and Live Q&A

Join Aaron Parecki and Micah Silverman from Okta for an hour of live Q&A about all things OAuth and OpenID Connect! Bring your questions, or just come to learn about what's new!

---

Music by Breakmaster Cylinder and Aaron Parecki

[rainerwahnsinn]

Really enjoyed this one. Fantastic questions. Thanks!

[rainerwahnsinn]

On the Authorization Code Injection Attack with PKCE. Couldn't the browser extension read out the PKCE secret from the storage and transmit it as well just like the authorization code? Since PKCE relies on JS reading out the secret, any XSS attack can do the same. 🤔 Sure, the browser extension needs to know the implementation details where the PKCE secret is stored, but this can be easily reverse engineered.

EDIT: Oh, watched a bit more along and this is answered in 37:38. The answer is, yes on public clients but not on confidential clients, since the plaintext secret never passes through the browser.

[sakethmanupati]

Question. I understood how hacker logged in as the target user. But how did the target user log in as his own? He got the auth code of the hacker. So when he logged in, he shd have logged in as the hacker since it is the hacker's auth code right?

[vivekmishra]

Why we are dumping the victim user back to login? Is it to prevent him from using the stolen authorization code?

[rainerwahnsinn]

On the Nonce vs PKCE debate. It seems the only reason from the OpenID side against PKCE, is that they wouldn't be 2.1 compliant anymore. Honestly, who cares? They are still 2.0 compliant. Why do they even care about 2.1? Is there a fine they need to pay if they aren't 2.1 compliant? I don't think so... I think compromising a whole spec just so you can patch yourself the label "2.1" on the back without doing anything, while even decreasing security for new implementations (since if they choose Nonce, they have the additional risk of leaking the access token, since it is issued to the client and just not used) is stupid.