Re: Why I can no longer support OAuth2 (was: Re: Why can't I pay using a Verifiable Credential?)

I think that while discussion can be had whether or not OAuth’s security model is appropriate in 2025 (especially with new protocols like GNAP and ZCAP), the criticism of OAuth being dependent on insecure bearer tokens is not reflective of modern best practice in high-assurance environments.

For instance, OpenID FAPI 2.0 explicitly specifies that conforming implementations must use *either* OAuth 2.0 mTLS (RFC 8705) or OAuth 2.0 DPoP (RFC 9449), both of which cover the threat vectors mentioned in the article. Message signing with HTTP Message Signatures is optional in case non-repudiation is required. OAuth 2.1, still in the draft stage, also mentions both RFCs, but stops short from recommending or requiring them.

In my opinion, the primary issue with OAuth, which is also highlighted in the article, is that it is a complicated patchwork of standards built upon a narrow model of authorisation. It’s optimised for implementation flexibility at the cost of varying levels of security guarantees in said implementations. If you properly implement high-assurance OAuth 2.0, however, you will have a modern, reliable, and secure system. The onus however is still on you and your counterparties to actually implement it properly, which is admittedly a big ask for certain organisations.

—
Marcus Engvall
https://www.linkedin.com/in/qasaur/

> On 17 Aug 2025, at 18:50, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Wed, Aug 13, 2025 at 5:18 PM Tim Bouma <trbouma@gmail.com> wrote:
>> Several months back I took a hard look at OAuth and what I learned from my implementation endeavour, I wrote this.
>> 
>> https://open.substack.com/pub/trbouma/p/why-i-can-no-longer-support-oauth
> 
> This is an excellent article, Tim. It matches our experience at
> Digital Bazaar implementing both OAuth2 and the OID4VCI/OID4VP
> protocols. We have repeatedly experienced developers in the ecosystem
> accidentally leak their credentials via OAuth2 because of a lack of
> understanding in how it works, or the pitfalls with "framework-based
> standards".
> 
> OAuth2 was what drove us to incubate and standardize HTTP Signatures,
> which does at least depend on cryptography to prove authorization.
> 
> Dick Hardt has recently written a related post on how OAuth2 is not a
> good fit for things like MCP (and how HTTP Message Signatures are
> better):
> 
> https://www.linkedin.com/posts/dickhardt_mcp-oauth-ai-activity-7358178115673616384-RKzc/
> 
> ... granted, he still tries to loop OAuth2 back into the mix (a
> mistake, IMHO -- we should just leave OAuth2 behind and move on to
> stuff like Authorization Capabilities), but dropping the complicated
> OAuth2 dances for clients is certainly an improvement.
> 
> In any case, just wanted to echo what you wrote Tim -- OAuth2 was
> better than sharing passwords a decade or more ago, but we need to
> move on to real cryptographic authentication, authorization, and
> delegation.
> 
> -- manu
> 
> -- 
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/
>

Received on Sunday, 17 August 2025 22:24:46 UTC