You could receive a spearphishing email from an AWS lookalike address, which includes a link to the real AWS login page, which you auth to legitimately but which then sends your credentials to somebody else.
This has a link expiry problem, as described in the article, but you can do similar things with e.g. a background tab that swaps itself out, starting the flow on demand when you go back to the tab.
That might catch quite a few people: a web page, which after X minutes in the background changes its favicon to AWS, and then next time you open it it immediately starts a device code flow and redirects to the real AWS login page. Looks just like you've gone back to an AWS tab that's just been logged out, and it's the real bone fide login so you can't tell the difference unless you remember where the tab came from. I imagine if you're working in AWS all day, it wouldn't be so unusual, and you'd just log in again.
Normally iirc oauth will just transport the token in a browser redirect to the allowed domain that linked to the login page. evil.com will not be allowed, or if it is the token will end up scoped to evil.com.
If evil.com requests access to manage my Twitter account, and it fools me into accepting, why does it matter how the token is transported? Evil.com now has access to my Twitter account.
This has a link expiry problem, as described in the article, but you can do similar things with e.g. a background tab that swaps itself out, starting the flow on demand when you go back to the tab.
That might catch quite a few people: a web page, which after X minutes in the background changes its favicon to AWS, and then next time you open it it immediately starts a device code flow and redirects to the real AWS login page. Looks just like you've gone back to an AWS tab that's just been logged out, and it's the real bone fide login so you can't tell the difference unless you remember where the tab came from. I imagine if you're working in AWS all day, it wouldn't be so unusual, and you'd just log in again.