NIP-98 HTTP Auth. I love this! Thanks nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 !!
Discussion
Very good stuff! Will implement support for this on some web apps 🤙
You wont regret it. I'm using this all the time now.
CC #[3]​
I’m not sure my use cases need a signed event per request, however it does maybe kill session cookies - but I still need to cache some local state like profile event and stuff anyway.
You can use it just for a login call and issue a cookie, no need to use it for every request.
Yep. Just a POST /auth or /login endpoint would work.
Client side session management can be tricky, as your can’t remotely kill/expire a user/device session. Nostr is a little different as your can’t exactly log out an apps/device’s access to a private key. I suspect if suspicious activity was detected you would flag/freeze that pubkey - however then how would you contact someone if pubkey maybe compromised.
I don’t know if some kind of cross-site scripting protection is needed. I’d have to think - however the relay AUTH nip includes a unique server/relay challenge code the event needs to include.
Re: challenge string. I feel there is an obsession with trying to protect everything from all of these theoretical MITM attacks. By including the host/relay, you resolve the worst concerns imo.
I’m with you. Can always be a hot fix or improvement later if issue.
Security is just very hard. And state based actors and centralised services (even CDNs) are a real threat going forward.
Be nice if we can eliminate risk from day one.
One other thought here.. it’s possible to use this for Relay Auth by sending the same in the websocket http connect header.
I don’t believe websockets should live longer than 30 minutes in the real world at scale (see LinkedIn, Facebook, Netflix, other engineering talks).
Perhaps it can even replace it.
Yep seems like a better way to do NIP-42 imo
I was advocating for exactly this and agree 100%. An optional header for NIP-42 is what we proposed.
The pushback I got was:
1) adding a second way to do AUTH is unnecessary protocol bloat.
2) web clients can’t send a header with a websocket connection
3) without a challenge string it doesn’t protect against MITM
I don’t agree with 1 or 3 and perhaps you have guidance on 2.
It is WAY better to do AUTH in a header if the socket is going to force you to do it on connection anyway. Relieves both clients and relays from having to address the REQ/AUTH race condition and prevents us from having to open and upgrade the connection just to fail AUTH.
I am totally behind this effort but tried once and failed.
I would like to add that this works best for Nostr Client <> API interaction.
If some external HTTP endpoint is being called from a nostr client it makes sense to use NIP-98
