Remember, OAuth 2.0 was designed to facilitate login by the big digital platforms at the time. Security was pushed out of the protocol and left to the implementors to handle. In the words of one of the the former editors “a recipe for security disaster”. I’m not making any claims, but as the world goes headlong into adopting a fundamentally insecure protocol for secure applications, I am keeping my eyes wide open.

I had #ChatGPT help me write this little apercçu on OAuth 1.0 and OAuth 2.0

——-

OAuth 1.0 vs OAuth 2.0 — and the controversy that shook the standards world

Most developers today are familiar with OAuth 2.0 — the framework behind “Login with Google” or API access via bearer tokens. But fewer remember that OAuth 2.0 was born out of a rather dramatic evolution.

OAuth 1.0 was cryptographically secure by design. Every request was signed with HMAC-SHA1 (or RSA), ensuring message integrity and protecting against replay attacks — even over untrusted networks.

Then came OAuth 2.0: simpler, more flexible, better suited for mobile and public clients. But it also abandoned signatures in favor of bearer tokens and shifted all trust to HTTPS.

That shift sparked major controversy. In 2012, Eran Hammer — the editor of the OAuth 2.0 spec — publicly resigned from the working group, calling OAuth 2.0 “a bad protocol” and “a recipe for security disasters.”

His key criticisms:
• OAuth 2.0 was too open-ended — leading to fragmentation and non-interoperability
• It offloaded security to implementers, many of whom weren’t equipped for it
• It prioritized ease of implementation over protocol integrity

In time, the industry adopted OAuth 2.0 regardless — and patched in best practices like PKCE, refresh tokens, and token revocation. OAuth 2.1 (in draft) now seeks to consolidate these lessons.

But the controversy remains a powerful reminder:
Simplicity isn’t free. It often comes at the cost of security, clarity, or control.

#nostr is the way