HTTP API, access control and API tokens

Kubuxu commented 8 years ago

This issue is here to sum up: need, possible solutions and discussions on the access control of IPFS HTTP API.

What?

Currently we have two APIs, full access API (on port 5001) and limited read only API (on port 8080). This is so websites can't interfere with functioning of IPFS node, change it settings, add files and so on.

This thread aims to change it, allowing full merge of full access and read only APIs.

Why?

In current state, Webapps built fully on top of IPFS, require users to manually tweak their configs to grant them full write access, this has ugly side effect of giving app completely full access to your node and makes IFPS Webapps much harder to use.

Solution

We should introduce API tokens, that would allow user to easily grant, revoke and limit access of some webapps.

Problems

This solution (as any) has it problems, main is storage of the secret token inside the webapp living in the browser, without separate security origin (as browsers do not handle ipfs paths in a way that we would expect).

My idea for the tokens is signed IPLD object very similar in format to JSON Web Tokens. We could also use JWT themselves as they are already libraries for handling them.

https://jwt.io/
https://github.com/ipfs/notes/issues/13
fs:/ security policy in FF: https://github.com/lidel/ipfs-firefox-addon/issues/71
previous API Tokens issue: https://github.com/ipfs/go-ipfs/issues/1532

ghost commented 7 years ago

Cool, @Kubuxu !!!

I am in a super urge to implement this myself. Before the villagers come after me with torches and pitchforks.

Do you have a plan to attack this?

Kubuxu commented 7 years ago

We are not really sure how it should work or how to continue but we would love to see any progress on it.

The cleanest solution so far seems usage of JSON Web Tokens as there are already libraries supporting.

Right now the most useful would be a draft for a spec which would allow us to agree on one thing. It would also have to define granularity of the tokes and me extensible for future (including changing format and splitting permissions).

ghost commented 7 years ago

The cleanest solution so far seems usage of JSON Web Tokens as there are already libraries supporting.

Agreed. JWT is the best. I used them for frontend sessions using an API written in golang, back in 2014, for a BTC exchange project I was working for.

Right now the most useful would be a draft for a spec

Will try my hand at writing a spec. Let's do this. Can you point me to any popular spec inside IPFS, so I can ~~steal~~ borrow ideas about the format?

Kubuxu commented 7 years ago

There is no strict format, checkout https://github.com/ipfs/specs/tree/master/repo or other files in this repo.

juanfranblanco commented 7 years ago

Will it help to use keys for a user and app. That might help to solve the origin problems, you have two tokens that could sign a transaction. App is public, user has a private key and a public key, ipfs can provide the jwt token with expiration, etc, which are signed using the private key of the user and includes the app key.

juanfranblanco commented 7 years ago

Focusing on the app to start makes more sense regardless

ipfs / notes