FEP-d8c2: OAuth 2.0 Profile for the ActivityPub API

Standards Fediverse Enhancement Proposals
, ,
41

Hi! I’m considering implementing RAR in my implementation. Is there any actual guidance for it (in the ActivityPub context) yet or should I just make something up (just to get the ball rolling, if anything)

42

There’s no standard yet for using RARs with activitypub nor server implementation APIs.

A few notes on your notes:

  • type should remain consistent throughout, currently your type is encoding privileges and locations.
  • for offline_access, use a scope, as per OIDC. RARs don’t replace Scopes, they supplement them.
  • the two additional fields sound like privileges on resources, or locations.

Though, bare in mind it’s extremely late for me, so this is just rough feedback

1 Like
43

type should remain consistent throughout, currently your type is encoding privileges and locations.

I’m not entirely sure if I understood this correctly, do you mean that all requests should have the same type? I feel like they’re different enough actions to warrant their own types (reading objects, sending, and receiving activities (the inbox and outbox names for those might not make that clear on a glance, should probably rename them)).

The proxy type could definitely be merged with read though.

for offline_access, use a scope, as per OIDC. RARs don’t replace Scopes, they supplement them.

I separated that out due to the “It is RECOMMENDED that a given API use only one form of requirement specification.” from the RFC’s guidance on interaction with scopes, but reading that again it likely refers to the same permission being granted two different ways, so using the scope here whould be fine.

the two additional fields sound like privileges on resources, or locations.

Could be, I haven’t exactly evaluated the privileges property yet. (edit: I apparently confused privileges with the permissions field from one of the examples. This definitely makes sense)

Though, bare in mind it’s extremely late for me, so this is just rough feedback

I definitely understand (my sleep schedule isn’t that well right now either, maybe it’s showing), I’ll probably have to revisit things myself as well, and given there’s more important things to implement (like client registration, which is still completely missing) thinking about this can definitely wait.

44

This!

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

If servers MUST provide the endpoints, they SHOULD at least also provide the oauthRegistrationEndpoint. Currently, the client developer experience unfortunately involves checking nodeinfo, or other heuristics to guess which software is used.

And, if we’re thinking about the developer experience, then adding RFC8414’s "/.well-known/oauth-authorization-server" endpoint would be the preferred method, this way we only need to ask the user for the server url.

EDIT, from the motivations section:

  • A client developer cannot manually register client metadata with each provider of the ActivityPub API.

This seems restrictive, basically requiring clients to be public. Either way this should be spelled out in a normative section.

1 Like
45

If servers MUST provide the endpoints, they SHOULD at least also provide the oauthRegistrationEndpoint. Currently, the client developer experience unfortunately involves checking nodeinfo, or other heuristics to guess which software is used.

And, if we’re thinking about the developer experience, then adding RFC8414’s "/.well-known/oauth-authorization-server" endpoint would be the preferred method, this way we only need to ask the user for the server url.

I personally prefer abandoning the AP oauth* endpoints altogether (given they’re missing endpoints for stuff like PAR, or definitions on what scopes/RARs are supported, etc) and simply linking to the oauth-authorization-server metadata as an endpoint. (Linking to it directly as opposed to simply looking up the endpoint under the actor’s ID allows for virtual hosting setups that may otherwise be difficult with a single global oauth endpoint, like horizontally scaling onto different instances under the same domain, without explicit support by the instance software)

4 Likes
46

Coming back to the Client Registration issue, I think the FEP currently lacks a discovery mechanism

The Web application discovers the oauthAuthorizationEndpoint to be https://home.example/oauth/authorize, and uses it to construct an URI for the authorization request, including scopes and PKCE parameters.

The presence of oauthAuthorizationEndpoint on the actor endpoints collection is a poor heuristic for the Server being compatible with this FEP.

Another issue could be CORS, a number of implementors (Pleroma for example) do not enable CORS on Actor objects (which may be a valid choice).

Perhaps this FEP could address CORS more directly, and offer an alternate discovery mechanism:

  • CORS SHOULD or MAY be enabled on the Actor URI
  • OAuth endpoints MAY be discoverable via Instance Actor (on which CORS MUST be disabled)
    With reference to
    - FEP-d556: Server-Level Actor Discovery Using WebFinger
    - FEP-844e: Capability Discovery (implements: FEP-d8c2)
1 Like