FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API


This is a discussion thread for the proposed FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.


This FEP defines a profile of OAuth 2.0 for use with the ActivityPub API.

1 Like

" Servers MUST provide the oauthAuthorizationEndpoint and oauthTokenEndpoint properties in the actor’s endpoints collection."

Why not use OAuth 2.0 Authorization Server Metadata


@yvolk This thread could be interesting for us.

The metadata elements called out in this FEP are also part of the ActivityPub spec. It would be weird not to use them.

Maybe we could add a MAY or even a SHOULD for the more mainstream OAuth 2.0 discovery?

It is also strange that the AP Spec says the same or similar thing as rfc8414. In the context of oauth2, I would want to stick more to rfc8414. It’s also weird if I use keycloak, for example, and then have to parse what keycloak provides again and provide it again.

Which part of the AP spec do you mean ?

Section 4.1 Actor objects. The endpoints property defines several standard endpoints and the OAuth endpoints are described there.


If OAuth 2.0 bearer tokens [RFC6749] [RFC6750] are being used for authenticating client to server interactions, this endpoint specifies a URI at which a browser-authenticated user may obtain a new authorization grant.


If OAuth 2.0 bearer tokens [RFC6749] [RFC6750] are being used for authenticating client to server interactions, this endpoint specifies a URI at which a client may acquire an access token.


that means each actor profile has the endpoints, although they are usually server-wide. Ok, theoretically I could authenticate certain Actors on another OAuth server :wink:

Instead of “Servers MUST provide the oauthAuthorizationEndpoint and oauthTokenEndpoint properties in the actor’s endpoints collection.

I would rather put it like this:
Servers MUST provide the authorizationServerMetadataEndpoint property in the actor’s endpoints collection.

In this case you could then specify the endpoint of the Authentication server, e.g. https://login.m4h.network/auth/realms/LOA/.well-known/openid-configuration which is a Keycloak endpoint.

I haven’t seen it done this way in practice but endpoints can be a AS2 Link object with an href to an actor-external document. That document could be instance-level, for example. Or it could be a mix. Some actors could have the same endpoints, but some special ones could have their own endpoints.

Yes, we have a few shared endpoints in there, like sharedInbox.

You can’t assume that the same server that the user account is on is the one they use for OAuth or shared delivery. This is a good thing, actually.

We already have the OAuth endpoints defined in AP. Defining an additional discovery mechanism for the same data is suboptimal.

How about we add a SHOULD for the host-based mechanism, for devs who are using toolsets that do discovery for them?

There are a few other advantages of providing only the OAuth Server Metadata URL in the AP Profile instead of the two endpoints directly. The OAuth Server Metadata document provides other information about the OAuth server, such as which scopes are supported, which extensions are supported (e.g. which PKCE hash mechanisms), and can be used to provide other endpoints in the future such as the PAR endpoint, the revocation endpoint, and more: OAuth Parameters

This would be a much more sustainable way to be able to support these kinds of additional metadata and extensions in the future rather than having to update an AP actor profile with implementation details of the OAuth server.

This also makes it a lot easier to use an external OAuth server that isn’t provided as part of the ActivityPub implementation. While I suspect that is not a concern for Mastodon since it takes a monolithic approach to ActivityPub, it is definitely a benefit for more of the lightweight implementations.

1 Like

absolutely! I meant by “that means each actor profile has the endpoints” → “that means each actor profile has the endpoints oauthAuthorizationEndpoint & oauthTokenEndpoint”.
It is a good practice to separate the AP server and the Auth server. I use keycloak as the auth server, so I want to touch as few auth things in the AP server as possible!

I don’t understand what you mean. You are talking about an additional “SHOULD” ?

@aaronpk What do you mean with ‘AP Profile’ ?
We have to take care with the term profile, because the server instance can also provide a profile.
so we need to distinguish whether we are talking about a user profile or an acitity-pub server profile.

Providing the OAuth Server Metadata URL in each user profile is not so meaningful in my eyes, but more flexible. I can’t imagine that there are activity pub implementations that use multiple different auth servers for actors. But theoretically someone might want to do that at some point. You have experience, do you think this is a valid requirement ?

Providing the OAuth Server Metadata URL in the ap server profile, is meaningful.

I agree that this doesn’t make sense for the typical monolithic stacks like Mastodon. But, there are a lot more different kinds of deployments than just Mastodon! For example Bridgy Fed allows you to federate your own website with other ActivityPub systems, but Bridgy Fed doesn’t provide an account that has any kind of authentication itself. That’s just off the top of my head, I’m sure there are a lot of other creative ways people have been bringing things in to the fediverse!

So, I don’t think “instead of” is on the table. We defined these endpoint properties in ActivityPub, and they are part of the specification.

Adding an additional property for the OAuth Server Metadata URL is fine; if someone’s already got a toolset that uses that URL for discovery, it can help out.

I don’t think that URL is necessary for this specification, however, since scopes, hash algo, and other items are defined in the document already.

This specification only talks about the actor profile. There is no well-defined way to discover the server actor, if it exists, given an actor profile.