Re: OAuth for the ActivityPub API Task Force

Yes I'd be happy to


On Sat, Aug 23, 2025 at 3:32 PM Evan Prodromou <evan@prodromou.name> wrote:

> If we had a task force, would you participate?
>
> On Aug 23, 2025 17:47, Aaron Parecki <aaron@parecki.com> wrote:
>
> 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
> >
> >
> >
>
>
>