Re: OAuth for the ActivityPub API Task Force

Please consider moving away from Dynamic Client Registration. It's
caused a number of problems for Mastodon and similar deployments, and
the more recent MCP community's use of it has also encountered the
same problems.

A recent MCP blog post goes into quite a bit of detail about this if
you would like the details:
https://blog.modelcontextprotocol.io/posts/client_registration/ (Note
that while this blog post is in the context of MCP, nothing about the
client registration problem is particularly unique to MCP, it just
happens to have the same problem as ActivityPub and BlueSky where
arbitrary clients need to talk to arbitrary servers without prior
relationships.)

BlueSky adopted the draft Client ID Metadata Documents as their
solution to the problem, and it looks like MCP will probably go that
route as well: https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/

Aaron

On Sat, Aug 23, 2025 at 2:41 PM Evan Prodromou <evan@prodromou.name> wrote:
>
> That's the second option.
>
> Evan
>
> On Aug 23, 2025 15:54, Mayel <m@mayel.space> wrote:
>
> Have you considered OpenID Connect? The discovery mechanism (using .well-known instead of manually configuring each endpoint URL) is handy, but dynamic client registration especially seems a necessity for ActivityPub (and would avoid having to use custom client registration APIs like Mastodon clients do)...
>
> On Saturday, 23 August 2025 at 8:10 PM, Evan Prodromou <evan@prodromou.name> wrote:
>
> Hi! As someone who has been developing sample applications for the ActivityPub API, I think we are at a critical point for defining an OAuth 2.0 profile (or profiles) for ActivityPub.
>
> OAuth 2.0 is the de factor standard for API authorization. It provides a way for applications to request access to a user's resources, and for the user to review that request and grant access. It also provides a way for the application to identify itself when making HTTP requests to the API.
>
> OAuth 2.0 is a pretty broad standard made up of a lot of RFCs, although it's excellently summarized in "OAuth Simplified" or https://oauth.com/ . In order for a client to use OAuth 2.0 for the ActivityPub API, I think it needs to know at least these things:
>
> - Which flow to use (usually "authorization code")
> - What the authorization endpoint URL is
> - What the access token endpoint URL is
> - What possible scopes exist
> - What client ID to use
> - Whether to use PKCE
> - Whether to use a client secret
> - What, if any, extra information is shared in the access token response
>
> There may be others; I'm not sure. I'm going to call a set of answers to these questions a "profile", which I think is pretty common.
>
> As far as I can tell, there are a few different profiles answering these questions on the Fediverse.
>
> - FEP d8c2 : Uses the oauthAuthorizationEndpoint and oauthTokenEndpoint properties of an actor for discovery. Uses an ActivityPub `Application` or `Service` object to represent a client, and its ActivityPub object ID as the client ID. Defines a small set of scopes. I wrote this so I'd have an OAuth 2.0 profile to work with for my AP API work, but it is difficult to use if you're using an off-the-shelf solution for OAuth 2.0, like KeyCloak or Auth0. - OAuth Discovery and Dynamic Client Registration: This is the solution used by Mastodon for its API (although there's no authenticated access to the AP API in Mastodon). It's also used by OpenID Connect. Discovery is used to get the authorization and access token endpoints, as well as the registration endpoint; registration is used to get a client ID. I think a lot of OAuth 2.0 libraries can support this, as well as servers like KeyCloak. There are a few big downsides; each instance of an app has a unique ID; apps don't have a universal ID across all servers (for reputation systems), and clients have to maintain a client ID for each server they interact with (could be tens of thousands!). The upside is excellent toolset coverage. - oauthRegistrationEndpoint: I think there are some Fediverse servers that use this undefined endpoint for their OAuth 2.0 flow. I think it lets the client go straight to dynamic registration, skipping OAuth discovery. I have no idea if any of the servers that use it also implement the ActivityPub API. As a client developer, I'm currently supporting FEP d8c2. I'm considering supporting discovery/registration, because at least one server developer has said they won't use any profile that can't be implemented without an unmodified KeyCloak. I'd like to suggest that we set up an OAuth Task Force for ActivityPub that documents all these options for client and server developers. Evan
>
>
>

Received on Saturday, 23 August 2025 21:47:42 UTC