Oh-Auth – Abusing OAuth to take over millions of accounts
Another issue with OAuth is the assumption that the browser part of the flow (where the real user enters their username and password on the issuer website) is actually done by a real user. When I was trying to automate EV charging, I looked at quite a few OAuth implementations and many of them were doing things like storing the user's credentials (including their password) then doing the entire OAuth flow with browser automation. I imagine this was the tip of the iceberg.<p>These days with a lot of non-standards-compliant OAuth implementations behind me, my conclusion is a lot of it is a giant waste of time, and it often adds completely pointless complexity for many of the cases it's used for. And as shown in the article, all the complexity often adds exploit vectors.<p>For 90% of API use cases just issue a revokable Bearer Token and be done with it. You are not an app platform!!!<p>[Qualifier: the EV API's I experimented with <i>were</i> a good use-case for OAuth, as they were user-first, based on mobile apps authenticated with user/password credentials. But I've worked with a lot of third party vendor API's where it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something]