[Poll] App Authentication Method Possibilities


#1

This is for both users and developers. Vote which one you think is best (while being feasible)!

(Do note I’m not part of Blockstack PBC, this is a community-run poll and there is no promise any of these alternatives will be implemented – I’m just figuring out what the community thinks about these and trying to start a discussion).

  • Current Method (persistent keypair & address, gaia token)
  • Session Token (persistent folder, gaia session token)
  • Injected API (persistent folder, browser handles everything)
  • Other (comment below!)

0 voters

Explanation

As I have been reviewing how app authentication works, I was thinking of different ways to go about it with varying security benefits (and amounts of work to implement). It might be that the one that is already implemented is the best way, and if so, great! But perhaps there’s a better way. Feel free to explain your position in the comments, or even argue for multiple options for apps to use.

Current Method (persistent keypair & address, gaia token)

Currently the App is given a public address and a private key to use, generated by and from the user’s own address/private key. They are also given a Gaia Token to use to store data in the hub, and if it expires the app is no longer able to write.

Security concerns: losing your phone/device while the app is still logged in, or having the app leak its key in some form (such as using it in a hidden backend API or XSS) would allow the “attacker” to misuse the encrypted app data as well as overwrite it – even if the browser had a session and was able to be logged out of remotely. In addition, if the association token is leaked, the attacker would be able to overwrite things (for a limited time, ~4 months) in private Gaia hubs.

Session Token (persistent folder, gaia session token)

Apps would be given a folder within the user’s Gaia bucket, such as hub.blockstack.org/{user address}/{app folder}, and would be given a token to have write access to that bucket. The address would be persistent but would not have a corresponding private key, and the token could be rejected/expired at any time if the session was removed.

Security concerns: data storage provider can track what apps you are using and what data really belongs to you. Apps can also use the session token outside of when the user is present, such as through a backend API or through other apps.

Implementation Difficulty: fairly easy, as all one would need is a new Gaia authentication method/token for both the Hub and the Browser and some changes to blockstack.js to handle it properly.

Injected API (persistent folder, browser handles everything)

Like the above, but instead of a session token being given to the app, the app uses the injected API to write into the user’s gaia hub. Folders no longer need to be permissioned with tokens and if the browser is disconnected the app can do nothing on the user’s behalf, therefore being more secure. The “browser token” is only a small token given to the app fro the browser so it would be able to do things securely with less of a chance to be spoofed.

Security concerns: data storage provider can track what apps you are using and what data really belongs to you.

Usage concerns: can no longer have write-access from backend services.

Implementation difficulty: very difficult, as an official extension would have to be made similar to MetaMask, blockstack.js would have to be rewritten to be able to be injected into websites, and apps would have to be rewritten to use the injected api instead of the included blockstack.js they have been using. Gaia could be left alone, however.


#2

I like the idea of an injected API from a developer perspective, also to better handle (in-app) payments.

I am concerned about the privacy implications of storage provider knowing about my apps. Can’t you mix the injected API with the persistent key pair?

Using persistent folders, centralizes the user’s data. You might want to store different app data on different gaia hubs (still to be implemented)


#3

Injected API’s also never go out of date (as long as there are no breaking changes), which is really cool to think about.

I do agree with the storage provider “peeking”, but to be honest, any app that you are sharing data on will have to have a reference to it in the profile.json anyways, giving away that you own that data in the bucket to everyone on the internet (including your storage provider). As for private data buckets (that aren’t sharing information with other people – only you!), odds are that data will be encrypted anyways so they won’t be able to do anything about it. In addition, persistent folders could be (optionally) obfuscated…

However, you could definitely mix the persistent key pair and the inject API. Technically we could have all three options given enough time to develop them, but for the specific example you are talking about, it would definitely give a degree of separation between your bucket and the app’s, while still being “super secure” as it’s all handled browser side. Best of both worlds!

Thank you for raising the point on data centralization as well – I can see now that different data buckets offer the ability to store them elsewhere, and without that, they all have to be on one provider. I personally think the solution to this would be having them in the persistent folders but they are within your identity’s buckets across the gaia hubs, i.e.

  • gaia.blockstack.org/{your-address}/stealthy.app/...
  • gaia.mydomain.com/{your-address}/graphite.app/...

Session tokens would then have a link to the gaia hub, and your browser would handle preferences of which apps would go where.