Add signature verification to PoC work for passport and keplr

[wgwz]

Relates to and builds further upon: https://github.com/regen-network/regen-registry/issues/895

This is the current PoC: https://github.com/wgwz/simple-express-keplr-passport

Currently the PoC provides up to point where a user will sign transaction in the front-end. The next step will be to pass the users address and this signature to the back-end for verification.

The goal of this task would be to verify that a user did indeed sign a transaction, and pending that, create a user session. The PoC already includes creating a user session for a username/password auth strategy. This task is to do a similar thing but I believe it will make use of the passport-custom strategy library.

[wgwz]

Hey team! Please add your planning poker estimate with ZenHub @blushi @mhagel

[wgwz]

@blushi , @mhagel When you have some time I'd appreciate some review on this PoC work. I completed the initial goals I had for this. I wanted to see a react front-end working with an express back-end, to authenticate a user through multiple methods.

There are two important files to review:

• The react front-end: https://github.com/wgwz/simple-express-keplr-passport/blob/master/frontend/src/App.tsx
• The express backend: https://github.com/wgwz/simple-express-keplr-passport/blob/master/backend/app.js

You should be able to run the app locally following the readme.

An important thing to be aware of if you do want to run it locally is you'll have to add yourself to the "database" here: https://github.com/wgwz/simple-express-keplr-passport/blob/master/backend/app.js#L46-L48

Once you've put in a password and a particular regen address for yourself, you should able login with either your username and password or by using your Keplr wallet.

You may need to press the keplr login button twice, in the case where you just typed in your keplr password.

In the case where you just want to see the important logic:

• Here is where the front-end creates and signs the transaction: https://github.com/wgwz/simple-express-keplr-passport/blob/master/frontend/src/App.tsx#L77-L108

• Here is the place where the back-end authenticates and verifies the transaction was signed by a given address: https://github.com/wgwz/simple-express-keplr-passport/blob/master/backend/app.js#L93-L149

There are some details to be aware of related to cookies and making authenticated requests to the back-end. Here's an example of how to make an authenticated call to the back-end: https://github.com/wgwz/simple-express-keplr-passport/blob/master/frontend/src/App.tsx#L24-L41

In short, we are using an http-only cookie that is set to expire after 24 hours. This cookie is unique to our domain, and as long as you tell axios or whatever your http client is to make use of it, those requests will pass along that info.

Thanks! And please let me know of questions

[blushi]

Thanks @wgwz, I'll review this early next week.

[blushi]

@wgwz I went through your PoC. Looks good overall. Some comments:

• As I said during our 1-1, we might need to think of some other strategy for storing user data on the front-end but the current version is fine as part of this PoC, the goal being signature verification after all
• Looking at code from commonwealth, it seems like they are actually using some validation token as part of the transaction to be signed (this token is generated on address creation) https://github.com/hicommonwealth/commonwealth/blob/master/client/scripts/controllers/app/webWallets/keplr_web_wallet.ts#L51, which is then verified on the back-end: https://github.com/hicommonwealth/commonwealth/blob/master/server/routes/verifyAddress.ts#L186-L198 I guess we'd want to add that extra layer as well.

[wgwz]

@blushi yeah, so i purposefully left that out, because i couldn't quite figure out why that had that extra layer there. it seemed like it was essentially a mechanism that allowed users to stop halfway through the account creation process or something. i wasn't sure if we needed that or not. it wasn't obvious to me so didn't want to add it at the moment. we can think through this more as we get closer to the real implementation i guess. i'm quite possibly missing something important from security perspective, so it'll be good to review.

[blushi]

@blushi yeah, so i purposefully left that out, because i couldn't quite figure out why that had that extra layer there. it seemed like it was essentially a mechanism that allowed users to stop halfway through the account creation process or something. i wasn't sure if we needed that or not. it wasn't obvious to me so didn't want to add it at the moment. we can think through this more as we get closer to the real implementation i guess. i'm quite possibly missing something important from security perspective, so it'll be good to review.

I believe this validation token is quite important from a security standpoint, it has the same value as a nonce to me, which prevents the user to sign malicious data, changing each time the user logs in. See this nice article from Amaury: https://www.toptal.com/ethereum/one-click-login-flows-a-metamask-tutorial, in particular "How the Login Flow Works" and "Why the Login Flow Works" sections.

[wgwz]

@blushi thanks, that makes sense now (thanks to Amaury too :-). i would like to at least demonstrate how to get the nonce and how can be used in the front and back-end PoC. i created a new issue for this: https://github.com/regen-network/regen-registry/issues/940

[blushi]

Sounds good, I'm fine closing this issue then and addressing the rest as part of #940