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.
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.
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 api/src/functions!
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.