Soliciting feedback for a major overhaul to the Ethereum Auth Client. Recently I “extended”
dbAuth to work with my own custom OAuth2, see Combining dbAuth + OAuth2.
I think we should completely overhaul
ethereum-auth package to extend
dbAuth, rather than duplicate efforts on the authentication side of things. We can just focus on the ethereum stuff! More explanation on github if you’re interested: [Discussion] "Extend" DbAuth · Issue #7 · oneclickdapp/ethereum-auth · GitHub
Ethereum explainer: In the context of authentication, ethereum user are their own “authority”, since they bring their own private keys via a wallet. When a user signs a message using this private key, the app can verify their identity, and create an account for them, issue a JWT or session, etc. This means we can authenticate anyone with an ethereum wallet without relying on any third-party services.
Thoughts? Concerns? Cat GIFs?
Is this really extending dbAuth, or just a new auth type that doesn’t depend on a third party provider? dbAuth still “thinks” it talks to a third party, it’s just that the third party happens to be a serverless function in
Could you just create a new auth client that, instead of doing a fetch here, invokes some web3 function to authenticate? redwood/dbAuth.ts at main · redwoodjs/redwood · GitHub
I do think that extending is better than separate. My plan right now is
- overwrite the web login function to pass a signed message instead of email/password
- overwrite the api login function to verify the signed message instead of email/password
After login, all the cookie/session management stuff can be exactly the same
But if you log out of Metamask or whatever wallet, you’d still be logged into the site since the cookie is still valid, wouldn’t you? Do you have to manually log out of the site once you get in, regardless of your wallet login status?
In web3, “log out” doesn’t really exist. Instead you often see “switch wallet”, or “disconnect” which allows you to switch to another address in your wallet. When people click that we can invalidate the cookie (is this a thing in dbAuth yet?).
So the only thing that can happen with the cookie in dbAuth:
- It expires
- It gets removed if you explicitly log out (which clears the content and sets it to expire on Jan 1 1970)
- Someone tampers with it, which means it won’t decrypt properly, and if it can’t be decrypted it gets removed
I think the concept of “invalidation” is more of a JWT/Oauth/“token” thing—cookies are either there or not there. They may expire, or not match a certain domain/path, in which case the browser won’t send them to the server.
@pi0neerpat if you’re convinced this is the way to go, we should put a deprecation notice on the current Redwood Ethereum auth provider. The upcoming v0.39 will be v1-rc, which means we’ve completed breaking changes and core features for v1.
@pi0neerpat are you still planning on doing an overhaul for the Ethereum package? If so let me know, would love to help out with that.
I would love to see this! Also happy to pitch in if that would be helpful