User authentication in decentralized applications
Alternatives over the Ethereum blockchain
One of the core decisions an engineer has to make while designing an application is how its users’ identity is going to be managed. While in traditional centralized client-server architecture this decision has already common patterns and protocols — in the decentralized world it’s still not there. I’m going to share our experience from designing the user identity management flow in our decentralized application, while working on Wemark’s first product that’s running on top of its digital property licensing protocol. In this post, I’m going to elaborate all possible solutions I know for this issue, followed by code examples written for the Ethereum network.
Option #1: The fully decentralized way
When talking about identity in the decentralized world, it’s completely public and unattached to any application. That’s the beauty of it — identity is shared between all applications and stored in the protocol layer (this is the vision). As a product developer of a fully decentralized application, you don’t really have to manage user authentication, which is given to you out of the box. The way users being authenticated is done by signing with their private key. This is done via Mist or MetaMask, which have to be installed. Once they unlock their account on these wallets/vaults, they can use it to sign any transaction initiated by your application.
Example
In this method you’ll have to use the injected Web3 instance by Mist or MetaMask (or any other in-browser wallet/vault).
Pros
- No need to handle user authentication, just use the injected Web3 instance
- Can be done completely from client side
Cons
- Users have to use Mist or MetaMask
Option #2: Use a private Ethereum client
After we’ve hacked DApps and have built a few products in the past, we now understand that managing user identities in a fully decentralized way is still far fetched if you want to integrate it in a real product. Users who have Mist or MetaMask installed are very few comparing to our total addressable market. Until blockchain accounts could be inherently managed by web browsers without any add-on, real products would have to manage it on their side. Ethereum clients such as Geth and Parity have the ability to create and manage accounts using their built in encrypted key store. In order to manage your users’ identities using it, you have to run your own Ethereum client, since no account management is available on public clients (and even if it is, you don’t want to rely on them right now). Communicating with the private Ethereum client is done with JSON-RPC protocol. All you have to do is just passing the user’s passphrase when creating or signing with their account.
Example
In this method you will get user’s passphrase by using an HTML form, or load it from any other storage that you own. Notice that in this example I’m using a proprietary Geth method for unlocking the account. After you unlock the account, Geth can sign transactions on behalf of it.
Pros
- Your users don’t have to use any special add-on like Mist or MetaMask
- Can be done from client side
Cons
- You have to run your own Ethereum client
- You’re limited to use this specific Ethereum client, since all users accounts are stored there
- Scaling is hard since you have to setup your own Ethereum clients cluster
Option #3: Act as a hosted wallet
The following method gives you the most flexibility, but since it involves managing the key store (or wallets) in your backend, it’s considered as less decentralized. Basically it’s a tradeoff between decentralization and UX. It means that in this solution you’ll have to store users key pairs in your DB and use this information to sign on transactions by yourself. Signing transactions is being done by using a hooked Web3 provider (like this one) that allows you to register a callback function just before the transaction is being sent to the Ethereum client.
Example
In this example I don’t use any helper library for managing key pairs, but you can definitely (or even should) use one (like this library by ConsenSys).
Pros
- Your users don’t have to use any special add-on like Mist or MetaMask
- You control users accounts so you can use any Ethereum client (public or private)
- Scaling is easy since there are many existing solutions for scaling a DB
Cons
- You have to manage and protect user accounts and serve as a wallet
- Not fully decentralized since key pairs are stored in your own servers
Conclusion
Managing user identities in a decentralized architecture has different approaches than in the traditional architecture of client-server. You can use in-browser wallets/vaults, your own private Ethereum clients or your own wallet to sign transactions on behalf of the user. Each one of the solutions above has it’s own tradeoffs, so it really depends on what you would like to achieve. I would love to hear your thoughts about this concern and share what you’ve picked for your use case.
