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
@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.
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!
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.
I actually called out in this issue (created separately later), that these oauth endpoints in the actor document are essentially re-implementing part of another existing standard, and that they likely should have never been in the specification in the first place, but instead a authenticationMechanism or similar should have been present (this would allow for OIDC-based authentication, or perhaps WebAuthn or any other number of authentication mechanisms)
Itâd also allow for future revisions of those specifications, e.g., had ActivityPub been written before OAuth 2.0, would we really have wanted to be tied to OAuth 1.0b?
Iâm very much so arguing that we should defer to and use existing standards where appropriate. I think itâs very unlikely that a server would allow one actor to authenticate in a completely different way to another actor (without all actors potentially being able to authenticate in that other way)
I fundamentally disagree with this FEP, and think it takes a very ânot invented hereâ approach. Using standards that already exist should be preferable unless thereâs a specific reason or value to deviate; Here in this FEP we stand to loose a lot of functionality of OAuth 2.0, and donât particularly gain anything (besides not having to do Dynamic Client Registration) â but DCR is valuable in other ways.
OAuth 2.0/2.1 is a well defined standard, maintained by the IETF, I donât think we should be doing something custom just because weâre ActivityPub and canât be bothered with implementing standards that we donât directly control. This creates interoperability issues and limits us in how things should work, reduces discoverability of metadata, etc.
We could take an approach more similar to the one defined in solid-oidc, which specifies that you can use a document URI as your client_id when registering the client, such that the details for that client come from an authoritative source, instead of having to provide all the fields when doing registration.
This FEP ignores the fact that you may indeed have confidential clients, not just public clients doing authentication. It all but ignores server to server flows, which impacts building applications for extending serverâs capabilities (e.g., something like IFTAS FediCheck or Newsmast)
Itâs list of scopes encouraging implementing OAuth 2.0 in ways that reduce consent and allow for data misuse. For instance, many applications that just want to authenticate a user and get basic data from your public profile, but instead they request read scope and now have full access to all your data (Iâve actually opened a PR to Mastodon to implement a read:me scope explicitly to reduce the amount of data an access tokens allows access to by default.
If we remember back to Cambridge Analytica, it was specifically this sort of requesting far more scope permissions in access tokens that were used to gain so much data about so many users, when all the users thought they were doing was signing into some game for fun. We should be educating users to be conscientious about giving access to their data.
Whilst right now the PKCE method of S256 is deemed a security best practice for public clients, itâs not actually necessary for confidential clients, and in the future S256 may no longer be secure enough, given advances in quantum computing or computing power in general, which has often resulted in many cryptographic algorithms becoming obsolete in time.
e.g., would we be better using DPoP tokens instead or in addition?
This FEP also further locks the ActivityPub ecosystem into OAuth 2.0 (maybe OAuth 2.1?), which seems ill-advised.