Atproto and mcp both picking oauth

ATProtocol and MCP are both picking OAuth as their authorization layer.

In both scenarios, the need is for a wide set of distributed participants that need to authorize, who can't do pre-registration of all the different endpoints that are available.

This is made possible by OAuth advancements like RFC 7591 Dynamic Client Registration:

The OAuth 2.0 Dynamic Client Registration extension provides a mechanism for dynamically or programmatically registering clients. This spec was derived from the OpenID Connect Dynamic Client Registration spec and is still compatible with OpenID Connect servers.

And increased security with RFC 9449 Demonstrating Proof-of-Possession (DPoP):

DPoP, or Demonstrating Proof of Possession, is an extension that describes a technique to cryptographically bind access tokens to a particular client when they are issued. This is one of many attempts at improving the security of Bearer Tokens by requiring the application using the token to prove possession of the same private key that was used to obtain the token.

Aaron Parecki who works on the OAuth spec has also written Let's fix OAuth in MCP which goes into more details.

UCAN as a way to delegate capabilities also plays in this space. I am actively looking for high value use cases where these OAuth approaches do not solve the problem.