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.
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.
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.
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!
@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!