Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication and restricting read access #13

Closed
joepio opened this issue Sep 16, 2020 · 5 comments
Closed

Authentication and restricting read access #13

joepio opened this issue Sep 16, 2020 · 5 comments

Comments

@joepio
Copy link
Member

joepio commented Sep 16, 2020

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
Copy link
Member Author

joepio commented Oct 10, 2020

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
Copy link
Member Author

joepio commented Mar 11, 2021

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
Copy link
Member Author

joepio commented Apr 26, 2021

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
Copy link
Member Author

joepio commented Nov 13, 2021

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 joepio changed the title Authentication Authentication and restricting read access Nov 13, 2021
@joepio
Copy link
Member Author

joepio commented Nov 13, 2021

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.

joepio added a commit that referenced this issue Nov 14, 2021
joepio added a commit that referenced this issue Nov 15, 2021
joepio added a commit that referenced this issue Nov 16, 2021
joepio added a commit that referenced this issue Nov 16, 2021
joepio added a commit that referenced this issue Nov 16, 2021
joepio added a commit that referenced this issue Nov 21, 2021
joepio added a commit that referenced this issue Nov 21, 2021
joepio added a commit that referenced this issue Nov 21, 2021
@joepio joepio closed this as completed Nov 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant