A possible alternative sign in/login process instead of firebase auth / amazon cognito using an eos contract?

Question

I had the the idea of a secure alternative login process using an EOS smart contract instead of firebase or Amazon cognito. I would like to know if something like this feasible?

My idea is somewhat like.

1. Server creates cookie with a specific id
2. Server sends cookie with id to client
3. Client gets cookie with unique id from server
4. Client wants to login so he executes a action "Login" from contract and writes the id he got from the server in the form of a SHA256 hash in the contract (contract writes the timestamp of execution also in the table)
5. Client sends message to the server when the action was successful that he wants to login.
6. Server looks up the EOS contract table for the name and if the entry is not older than 1-2sec and checks if the hashed id is the same as the server gave to the client.
7. If everything is ok, the client gets a session and can see his private data or whatever the website returns.

(server could be something like node.js with express-session and reactjs/vue/angular as front-end)

I don't know if this is a secure way to do this or an alternative for firebase auth and amazon cognito. I would also be interested in other thoughts, how one could realize something like that.

Answer 1

I don't see any reason for something like this not to work. Please keep us informed of your progress!

Things to keep in mind:

• It takes ~2.5 minutes for the login action to become irreversible. So it is possible that if your server is looking at a microfork, it won't see the login attempt.
• What if someone tries to log in with your credentials shortly after you push the action to login?

Answer 2

I know that DMail uses a nonce challenge response authentication to verify that you control a particular eosio account(or key, can't remember). Its basically what you are describing except it doesn't require an action to be pushed to the chain. If someone wants to authenticate as a particular account the sequence I think would look something like this:

1. Client tells server they want to authentication as account11111
2. Server looks up public key for account11111 from eosio blockchain
3. Server sends client a nonce to sign with the private key for account11111
4. Client performs an arbitrary signature of the nonce provided by the server and sends it back (scatter allows this)
5. Server validates the signature is valid with the public key for account11111 and generates a session allowing access to private data