Authorization on Commun/: Web3 or not?
Hi, Commun/! The goal of this article is to reveal the details of the authorization process in our social network.
First of all, let me remind you what the typical web3 flow (https://kauri.io/how-to-achieve-user-authentication-by-web3-wallet/a7a3198e2673406aa730d41854871e1a/a) is:
1. The minimal frontend code uses web3js to request the user to sign a message using their web3 enabled browser.
2. The backend receives the message and makes sure that the person who signed it is the one who called the controller login action by comparing the public key of the user with public key that is extracted from the signed message.
3. If the login is successful, a jwt is generated by spring security and we send it back to the frontend.
4. Frontend uses the jwt to call authenticated actions.
Many people think that using such third-party services as MetaMask or Mist is a necessary requirement but that’s not quite true. In fact, the main difference between web3 authorization and an ordinary one is that the approval or disapproval of the validity of the pair “login-key” is made by the blockchain. This approval is kept and transferred by a signed JWT, which is stored on the client side, usually as a cookie-file.
Let’s take a look at what distinguishes our approach from the basic web3 approach. Commun/ is a unique project. One of the reasons for its uniqueness is that it doesn’t collect, therefore, doesn’t keep any sensitive data. Firstly, the authorization executes a cosmetic function - an indication of the user-specific data; secondly, hide from users some pages or data that could confuse them. For example, why should the user see the control panel of the community if he/she isn’t an active leader and won’t be able to use it? Nonetheless, it is possible to retrieve any information using a block-explorer.
However, despite everything mentioned above, once there’s an authorization on the platform, then it should be secure. I want to draw the special attention of the reader to the fact that we are only talking about authorization in the application but not in the Cyberway blockchain (to execute a transaction).
1. The client opens wss connection with a gate-server of Commun/
2. Gate generates an unique id (UUID) for a socket-channel, informing auth-service about a new connection
3. Auth generates a cryptographically secure random secret string for this channel and provides it to gate-service (remembering a pair “id-channel ← → in-memory secret”)
4. Gate provides this string to the client through the same socket connection
5. The client receives an active key from the user (or uses a locally saved one) and signs a secret to them; transfers a signed line and user’s login back to gate service; the gate service then streams the same message to the auth-service
6. Auth service controls the correspondence of the following requirements:
⠀a) The signed secret matches the one that has been generated for that ⠀particular channel;
⠀b) Public key extracted from the secret’s signature matches the one⠀ that⠀has been saved for this login in the Cyberway blockchain.
8. Otherwise, gate-service stores in-memory the confirmation of the channel authorization for a particular user and send a message about it to the client
9. Later on, any request to the backend part of the application through that socket channel will be authorized for that user
10. In case of rapture/disconnection of the channel, all authorization data is deleting and all steps are performed anew
Thus, we can make the following conclusions: the approach of Commun/ Auth matches the web3 one, all the differences are due to the specifics. For example, there’s no need to decrypt JWT every time, no additional network load, possibility of “man-in-the-middle”-like attacks are reduced because they are complicated, the working speed is higher, the control is simplified.
What do you think? All the criticism/thoughts are welcome!