HTTP API, access control and API tokens

[Kubuxu]

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.

Related:

• https://jwt.io/
• Authenticated HTTP API for using IPFS from browsers #13
• fs:/ security policy in FF: Origin policy for fs: URIs ipfs-companion#71
• previous API Tokens issue: API Tokens kubo#1532

[ghost]

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]

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]

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]

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

[juanfranblanco]

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]

Focusing on the app to start makes more sense regardless