HTTP API, access control and API tokens #159
This issue is here to sum up: need, possible solutions and discussions on the access control of IPFS HTTP API.
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.
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.
We should introduce API tokens, that would allow user to easily grant, revoke and limit access of some webapps.
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.
The text was updated successfully, but these errors were encountered:
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).
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
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.