Thanks to nostr:npub179e9tp4yqtqx4myp35283fz64gxuzmr6n3yxnktux5pnd5t03eps0elz4s calling me out on the ease of use of npub.cash, I am working on a OTP type login.
The user will enter their pubkey to login. The server generates an one-time-password and send it to this pubkey in an encrypted DM. The user can then enter the OTP in the browser window and obtain a session token.
This will dramatically increase the UX on mobile devices and offer a more sure way to login vs. raw nsec.
I am thinking of adding this to nostr-login, it will need server-side support by the app ofc.
Questions:
- do you think there is any particularly good approach we could take that would help us make otp server api a nip?
- what if instead of server issuing a session token client would generate a session key and sign otp with it, the server could use this npub as session id, client could use standardized stuff like nip98 to sign requests, etc. Is this a good idea?
Tricky… I am not sure if using a nostr key instead of a session token is a good idea, as it would need to be inherently less secure.
A session token can be a http only cookie, while a nostr key would need to be accessible to JavaScript in order to be useful, making it vulnerable to XSS.
If this leads to the conclusion that a session token shall be used, then a NIP doesn’t make sense either, as it’s not really a nostr centric thing anymore.
Good point. Ok I will experiment with it too, maybe it's gonna be simpler with a simple cookie
