ActivityPub: Authentication and Authorization
ActivityPub uses authentication for two purposes; first, to authenticate clients to servers, and secondly in federated implementations to authenticate servers to each other. While ActivityPub's core specification does not specify an official mechanism, the community has converged on the most common practices.
Client to Server
ActivityPub clients authenticate against a server using OAuth 2.0 bearer tokens.
Bearer tokens may be acquired out of band. They may also be acquired using OAuth 2.0 authorization. To discover the correct endpoint for authorization, clients should use OAuth-Server-Metadata on the host part from the actor's ID URI.
Client IDs may be acquired out of band for some servers. They may also be acquired using RFC7591.
Server to Server
Signing requests using HTTP Signatures
Server to server federation is authenticated using HTTP Signatures in conjunction with the signing key from the actor's publicKey field. The keyId should link to the actor so that the publicKey field can be retrieved. At minimum, the digest field should be included in the set of headers being signed.
Linked Data Signatures
For most forms of delivery, HTTP Signatures is enough. However, some objects may be passed around the network, whether being shared, forwarded, or otherwise referenced at a future time. In this case it is important to be able to verify that the actors specified in the actor and attributedTo fields really did author the objects they are being claimed to have authored. In such a case we need to be able to verify the integrity of the object being passed around, and so we must sign the object itself.
For this we use Linked Data Signatures to sign the object with the publicKey of the actor that is the actor or attributedTo of the object being passed around the network.