search

nostr-protocol / nips

Nostr Implementation Possibilities
2.37k stars 572 forks source link

enable clients to initiate NIP-42 authentication #1050

Open mleku opened 8 months ago

mleku commented 8 months ago

currently in the protocol there is no means for the client to request authentication, this means that clients cannot preemptively authenticate when they see authentication required in the NIP-11

since the AUTH envelope already has a dual form implied by the role (client or server) adding another form for this would be cumbersome to parse, it is already a pain as it requires checking if the second field is a string or an object

so, my suggestion is to make the client auth request just an empty ["AUTH"] and this will be a third differentiator - the parsing code has to already look for { or " so it's no big deal for it to look for ] as well, then all existing code that is based on the relay demanding auth will still work the same just that the client can make this request

there may be some issues with spammy triggering of this from clients, but i think it should be simple enough to understand to only send it once and wait

it is possible, of course, for a relay to just send out an auth challenge upon connection, as well, but there is no signal from the client that they support it

i'm just trying to work out a way to fit it into the client authentication flow, as i have had to write a workaround in a chat client because although the signatures can be regarded as authentic it's possible for an attacker to replay a captured signed event and run off on its own and not pass that back to the client, and then do all the auth things

i have raised this issue in a previous issue about removing the requirement of the relay so that proxy relays become simple to implement, but it did not get a good reception and i think ultimately everyone needs to knuckle down and make auth work because there is so many problems that can be solved by requiring it, especially relating to paid relays and spam control

monlovesmango commented 8 months ago

heres a relevant discussion we've had around this topic: https://github.com/nostr-protocol/nips/pull/891

this https://github.com/nostr-protocol/nips/pull/891#issuecomment-1823245472 summarizes some of the previous PRs pertinent to that discussion.

mikedilger commented 8 months ago

I am not against allowing clients to initiate AUTH. But I don't see the benefit when clients and relays are well-behaved. AUTH is for the benefit of the relay, not for the benefit of the client. My client (gossip) isn't going to offer to AUTH to a relay that didn't ask for it, and my relay (chorus) offers AUTH to every client immediately upon connection.

Clients should just ask for what they want. If they get an "auth-required" then they can AUTH and ask again. But I realize this is another round-trip and maybe harder for some people to code, which is why I'm not strongly opinionated on this.

It's no big deal to me either way.

alexgleason commented 8 months ago

I think it could simplify some flows if the client could authenticate first. A way to do it would be to sign a NIP-98 event for a GET request where the URL is the relay URL, and send that in an AUTH message. I'm not advocating for it, I just wanted to share my clever solution. I think the auth flow is mostly fine.

staab commented 8 months ago

I have recently switched to "let clients initiate" as well. I do agree with what Mike said, but the best design I've found for allowing clients to present an external claim to a relay to gain entry is via AUTH, see https://github.com/nostr-protocol/nips/pull/1079

fiatjaf commented 8 months ago

I don't get the entire point of "letting clients initiate". It makes no sense because there are only two possible scenarios

  1. if the relay is not prepared to handle the client's AUTH then it will have no effect;
  2. if the relay is prepared to handle a client-initiated AUTH, then it should just send an AUTH challenge to every client immediately upon connection (like many relays already do).

What am I missing?