OAuth 2.0 - Revision history

Tom at 23:33, 7 August 2025

2025-08-07T23:33:53Z

2025-08-07T23:30:14Z

‎Security Controversy

2025-08-05T23:08:31Z

‎Security Controversy

2025-07-21T01:35:39Z

‎Solutions

2025-07-21T01:34:53Z

‎Solutions

2025-07-10T16:51:29Z

‎Security Controversy

2025-07-10T16:45:12Z

‎Security Controversy

2025-07-10T16:41:51Z

‎Solutions

2021-04-28T16:20:50Z

‎Problems

2020-02-20T22:13:11Z

‎References

@@ Line 38: / Line 38: @@
 Simplicity isn’t free. It often comes at the cost of security, clarity, or control.
-* From Eve Maler FWIW, here was my commentary at the time (bit rot seems to have dropped my Venn diagram from the post — I’ll try to unearth it — and Forrester removed my name when I left…). https://www.forrester.com/blogs/12-08-08-identity_protocol_gut_check/
+* 2018-08-08 From Eve Maler FWIW, here was my commentary at the time (bit rot seems to have dropped my Venn diagram from the post — I’ll try to unearth it — and Forrester removed my name when I left…). https://www.forrester.com/blogs/12-08-08-identity_protocol_gut_check/
 * From Tom Jones Yes OAuth 2.0 suffered from weak security,

@@ Line 28: / Line 28: @@
 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.”
+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

@@ Line 46: / Line 46: @@
 ** This is the wrong paradigm and is the source for privacy problems.  Lets switch away from leaking user private information to just getting secure access tokens.
 ** This is the basis for OID4VP which is clearly not aligned with user informed consent.
 ==Solutions==

@@ Line 50: / Line 50: @@
 *Switch OAuth from [[Bearer Token]]s to [[Bound Token]]s
 *Justin Richer has some suggestions.<ref>Justin Richer, ''Moving On from OAuth 2: A Proposal.'' https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade</ref>
-* Developers are pushing back on the idea that nobody cards about OAUTH anymore https://www.scottbrady.io/oauth/why-developers-do-care-about-oauth-and-openid-connect
+* 2019-01-27  Developers are pushing back on the idea that nobody cards about OAUTH anymore https://www.scottbrady.io/oauth/why-developers-do-care-about-oauth-and-openid-connect
 ==References==

@@ Line 50: / Line 50: @@
 *Switch OAuth from [[Bearer Token]]s to [[Bound Token]]s
 *Justin Richer has some suggestions.<ref>Justin Richer, ''Moving On from OAuth 2: A Proposal.'' https://medium.com/@justinsecurity/moving-on-from-oauth-2-629a00133ade</ref>
 ==References==

@@ Line 6: / Line 6: @@
 ==Problems==
-* OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until quantum computing arrives.
+* OAuth 2.0 still depends on shared secrets between services on [[Web Site]]s and other internet devices;<ref>Justin Richer, ''What's Wrong With OAuth 2?'' https://twitter.com/justin__richer/status/1023738139200778240</ref> while most sites are protected by public keys and certificates, at least until [[Quantum Computing Threat]] arrives.
 * It is still just a collection of parts that can be configured in a wide variety of combinations; most of which are not particularly secure.
 * Token type "bearer" is still the only one used in real-world implementations. See the page [[Bearer Tokens Considered Harmful]] on this wiki.

@@ Line 26: / Line 26: @@
 # RFC 6749 The OAuth 2.0 Authorization Framework specification
 # RFC 8252 OAuth 2.0 for Native Apps Specification
 # [https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce/?utm_campaign=text_website_all_multiple_dev_dev_oauth-pkce_null Proof Key for Code Exchange (PKCE)] - Micah Silverman Okta - ''Implement the OAuth 2.0 Authorization Code with PKCE Flow''