OAuth 2.0 Auth Code Injection Attack in Action

Here are some useful/foundational links for learning about OAuth 2.0:

Okta is a developer API service that stores user accounts for your web apps, mobile apps, and APIs.

[KDOERAK]

By watching this vid, I became a more informed person: my time was well spent - thx!

[sebastiangonzalez]

Very clearly illustrated, thanks for explaining and demoing this!

[nawwark]

Are there other attack scenarios that don't require a malicious browser extensions (or compromised user agent or MITM)? I don't know much about browser extensions, but don't they already have access to cookies, browser storage, and/or the page's DOM? Therefore session hijacking can already be done in different ways at that point?

[sp-vtje]

PKCE or not, shouldn't the authorization server return the authorization code directly to the back channel (server) as opposed to the front channel? In which case there is nothing an attacker can intercept directly....also the statement "there is no way to know the code verifier" is debatable. If a browser extension can intercept your Http calls it can also access the state in the browser if it knows where to look and grab it.

[baptiste]

But isn't the back channel supposed to send the code along with some secret to the authorization server of Google ? I thought the need to have a front and a back channel was specifically aimed to prevent this kind of attacks where someone could replay your auth code but as it does not have the client secret the auth server would not grant the access_token.

[keremserttas]

I have question. If the auth code is for single use. How can both attacker and the target user can use this single use code with the application?