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

HTTP API, access control and API tokens #159

Open
Kubuxu opened this Issue Aug 24, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@Kubuxu
Copy link
Member

Kubuxu commented Aug 24, 2016

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:

@hermanjunge

This comment has been minimized.

Copy link

hermanjunge commented Oct 13, 2016

Cool, @Kubuxu !!!

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

3

Do you have a plan to attack this?

@Kubuxu

This comment has been minimized.

Copy link
Member Author

Kubuxu commented Oct 13, 2016

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).

@hermanjunge

This comment has been minimized.

Copy link

hermanjunge commented Oct 13, 2016

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

This comment has been minimized.

Copy link
Member Author

Kubuxu commented Oct 13, 2016

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

@juanfranblanco

This comment has been minimized.

Copy link

juanfranblanco commented Oct 14, 2016

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

This comment has been minimized.

Copy link

juanfranblanco commented Oct 14, 2016

Focusing on the app to start makes more sense regardless

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment