Authentication and restricting read access

[joepio]

docs: atomicdata-dev/atomic-data-docs#55
front-end: atomicdata-dev/atomic-data-browser#108

Write actions should only be possible for authenticated users. Currently, I haven't even implemented write capabilities on the server because of the lack of authentication methods. Write actions are now done using signed commits, so they're safe.

For reading items, it might be a good idea to start off with an OAuth 2.0 implementation, (some nice rust libraries exist, such as oxide-auth), but still seemd kind of complex. Perhaps, for now, it is good enough to work with some API key that is sent with every request to a protected endpoint.

[joepio]

I think we could have Commits without conventional authentication, since these Commits use signatures. This should still be implemented, though, but it solves the write part, at least.

[joepio]

I'm looking for a clean, simple way to let the server know which agent is making some request. Usually what happens, is that the one making the request has to sign some message from the server to prove ownership over some key, and after that a temporarily usable token is stored as a session / device cookie.

If the client posesses a private key (which is currenlty used in Commits, too), we could use that key to sign a request. Perhaps have a signature and agent HTTP header, after which the server checks if the agent's public key and the signature are OK. The signature message source could be the requested subject + the current timestamp + the agent subject. This combination should be unique for each request.

Checking this for every single request seems a bit tedious, so we should probably use a session token, so the server only has to do the signature checking once for every session.

[joepio]

So a couple of methods exist to sign HTTP requests. One is to add a Digest and Authorization HTTP header. Another way is to add a Body with a JWS (or other signature) that contains information about the request, such as the requested resource and some fleeting identifier (timestamp).

[joepio]

I think the sign(timestamp + subject) approach is pretty valid. I'll start working on an implementation.

The request needs to include the signature, the timestamp, and the public key of the agent.

  const privateKey = agent.privateKey;
  const timestamp = getTimestampNow();
  const message = `${subject} ${timestamp}`;
  const signed = await signToBase64(message, privateKey);
  headers.set('x-atomic-public-key', await agent.getPublicKey());
  headers.set('x-atomic-signature', signed);
  headers.set('x-atomic-timestamp', timestamp.toString());

[joepio]

Authorization can be costly, so let's make some simple optimizations to prevent large performance regressions.

First, the server needs to decide whether authentication is necessary at all. If a resource is public, skip it. Also, if the user is an admin, skip further checks.

If the resource is for specific eyes only (recursively check parents for read rights), continue.

The server needs to parse three headers.

After that, the server needs to find the Agent corresponding to the public key. This could be a ValueIndex request.