Hello!
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.
Summary
This FEP defines a profile of OAuth 2.0 for use with the ActivityPub API.
" Servers MUST provide the oauthAuthorizationEndpoint and oauthTokenEndpoint properties in the actorâs endpoints collection."
Why not use OAuth 2.0 Authorization Server Metadata
Fredy
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.
oauthAuthorizationEndpoint
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.
oauthTokenEndpoint
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 
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.
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!