Deprecation of oauth* endpoints in Actor objects

[ThisIsMissEm]

Given that these endpoints and how to use them are far better described by RFC 8414's /.well-known/oauth-authorization-server document, which is a widely supported standard, the presence of the OAuth endpoints in Actor objects ties ActivityPub to OAuth as an authentication/authorization mechanism, when this could be discovered by querying for a well known document instead.

This document defined in RFC 8414 is also mostly used by OIDC which uses .well-known/openid-configuration, OIDC also supports discovery via Webfinger request where the link value is http://openid.net/specs/connect/1.0/issuer

Deprecating the properties oauthAuthorizationEndpoint and oauthTokenEndpoint would allow for additional authorization/authentication mechanisms to be experimented with, and would remove the duplication of things already well specified by OAuth 2.0, OAuth 2.1, and OIDC specifications.

[ThisIsMissEm]

This is a follow up to #409 which takes a different approach of proposing we deprecate those endpoints entirely in Actor documents and prefer following other standards.

Perhaps what could be done is to add a property such as authenticationMechanism which is a string representing which specification should be followed for doing authentication, and pre-register oauth2.0, oauth2.1 and oidc?

[evanp]

I am -1 on this. I find these endpoints really useful, and I find the process of endpoint discovery in the actor document to be helpful. FEP-d8c2 uses these endpoints.

Perhaps if we can see another profile defined for OAuth 2.0 and ActivityPub that doesn't use these endpoints, we could use it instead. I still really appreciate the simplicity and directness of this mechanism.

[ap-socialhub]

This issue has been mentioned on SocialHub. There might be relevant details there:

https://socialhub.activitypub.rocks/t/fep-d8c2-oauth-2-0-profile-for-the-activitypub-api/3575/19

[ThisIsMissEm]

For what it's worth, Mastodon has added implementing RFC 8414 to their 4.3 milestone, so there's a strong probability that this will land given the PR should be in a mergable state: https://github.com/mastodon/mastodon/issues/24099

[evanp]

@ThisIsMissEm Mastodon only partially supports the ActivityPub API.

[ThisIsMissEm]

@ThisIsMissEm Mastodon only partially supports the ActivityPub API.

As do many other fediverse projects, such as Pixelfed, PeerTube, Lemmy, Kbin, NodeBB, Threads, etc.

Even if these properties are only useful for C2S, it would still be better to defer/delegate to the OAuth 2.0 discovery mechanism as defined in RFC 8414, since that's going to make interoperability much simple.

Assuming scopes, algorithms, authorization flows, etc isn't a good practice.

[aaronpk]

I commented this on the socialhub thread, but I'll say it here too for posterity.

I’m surprised to see that ActivityPub defined the two OAuth endpoints in the actor object in the first place. I would argue that was an error on our part (as the working group) since we made the explicit decision to leave authentication/authorization out of scope of the draft.

If I follow the breadcrumb trails, the “Authentication and Authorization” section links to a wiki page here: ActivityPub/Primer/Authentication Authorization - W3C Wiki which says:

To discover the correct endpoint for authorization, clients should use OAuth-Server-Metadata on the host part from the actor’s ID URI.

That sentence was in the original version of that page from 2017, before the final publication of ActivityPub: ActivityPub/Primer/Authentication Authorization - W3C Wiki

So even the ActivityPub spec when it was published had two contradicting ways to find the OAuth server, one of which ignored the “follow your nose” method entirely.

I think it’s best to remove the oauthAuthorizationEndpoint and oauthTokenEndpoint properties in the actor profile and do something that makes more sense now.