SocialCG/ActivityPub/Authentication Authorization

From W3C Wiki
Jump to: navigation, search

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.

Unfortunately at the time of standardization, there are no strongly agreed upon mechanisms for authentication. Some possible directions for authentication are laid out as follows.

OAuth 2.0 and JSON Web Signatures

ActivityPub implementations may use OAuth 2.0 with JSON Web Signatures RFC7515 for authentication and authorization. This has the advantage of wide deployment of OAuth 2.0 technologies. However, OAuth 2.0 technologies are frequently incompatible, and the agreed upon mechanisms for deploying via OAuth 2.0 are still in flux, so it is not feasible to recommend a general pattern for OAuth 2.0 based deployments at this time.

Client to Origin Server Authentication

For client to server interactions where the client is interacting directly to the actor's server, clients may use OAuth 2.0 bearer tokens to authenticate.

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.

Client to Foreign Server Authentication

For client to server interactions where the client is interacting with servers beyond the user's origin server, clients and servers may support use of OAuth 2.0 with JSON Web Signatures.

Servers Acting on Behalf of Users

Servers performing operations on behalf of a user (e.g. delivery to a recipient) may use OAuth 2.0 with JSON Web Signatures to authenticate with a 3rd party server.

Linked Data Signatures and HTTP Signatures

ActivityPub implementations may use Linked Data Signatures and signed HTTP messages for authentication and authorization. (Linked Data Signatures are best used when authentication is meant to be "long lived" and attached to an object, such as verifying that an object truly was posted by this actor, and signed HTTP messages should be used when authentication or authorization is ephemeral.) This has the advantage of clean integration with existing JSON-LD based technologies already used by ActivityPub. However, at the time of specification, Linked Data Signatures and HTTP signatures are very young, particularly in adoption.

When Linked Data Signatures is used in combination with ActivityPub, the server should assign an actor a public and private key pair, and link the public key to the actor's profile object, which may later be used with the Linked Data Signatures verification algorithm to validate the authenticity of messages passed along the network.

Client to Origin Server Authentication

For client to server interactions where the client is interacting directly with the actor's server, a client may use HTTP signatures by registering their client's public key with the actor on the server and subsequently using this key to sign any HTTP requests made.

Client to Foreign Server Authentication

For client to server interactions where the client is interacting with servers beyond the user's origin server, clients may use a combination of HTTP signatures and Linked Data Signatures.

In this scenario, a client would have their client key authorized for a limited window of time by the key listed on their actor profile. The client key would then be used to sign HTTP requests made to the foreign server while also providing the signature of the client public key, signed by and linked to the key on their actor profile.

Servers Acting on Behalf of Users

Servers performing operations on behalf of a user (e.g. delivery to a recipient) may use Linked Data Signatures to authenticate with a 3rd party server. This may be achieved by attaching the linked data signature to the activity posted to the remote inbox, signed by the actor's public key.

Servers receiving activities verified via Linked Data Signatures SHOULD NOT process an object with a nonce they have seen before, so as to prevent replay attacks.