LGTM, I will implement this in clients and servers

• https://nosdav.com/spec/
• https://nosdav.com/server/

And in client side apps

• https://nosdav.com/apps/

I've yet to implement method tag, but I will soon

How is the event delivered to the API? Is it published to a relay? I would be concerned about replay attacks, this doesn't seem secure. I don't understand why a direct request wouldn't work, is this for delegating authentication?

How is the event delivered to the API? Is it published to a relay?

Authorization header is a request header in HTTP

I would be concerned about replay attacks

Idempotency can be managed by the API and is not a concern for this spec, timestamp checks should be good enough in most cases.

Ah, ok, I missed that. LGTM I guess then. This is a criticism of zaps as well, but it's strange to use the standard event structure but then encode it and throw it in some other place like a query string or authentication header rather than just using a regular HMAC or signing the url you're requesting directly or whatnot. Putting it all in a valid event makes me worry that a confused client will publish this event, which contains sensitive information, to relays, which is possible and definitely not what you want to do.

The main reason for using nostr events is that we already have infrastructure to create signed payloads via NIP-7.

Suggesting something like regular HMAC auth would require access to private keys or changes to NIP-7, we have a JSON object which is similar to JWT here and i see an opportunity to re-use the nostr identity in external systems over regular HTTP requests.

I would even go so far as to say that this should be used instead of NIP-42! Its much cleaner to auth to relays this way.

Is this the spec we want for all "Nostr login" use cases?

@Dolu89 @lukechilds can you take a look at this?

It's interesting reading this proposal, coming from some slight use of JWTs with shared secrets on servers.
JWTs typically have an auth provider authenticating a user and also validating "claims" (authorization roles).
The JWT is passed in the Authorization Bearer _ HTTP header along with the actual resource request.
The server can then validate identity and claims via symmetrical shared secret, or alternatively via jwk_url for asymmetric auth.

Clearly for Nostr we want to auth users asymmetrically. It is technically possible for Nostr clients to generate their own JWT for id. To validate permissions to a resource, an organization would have to run their own auth service, use Nostr to validate id, but add claims to the JWT.

Wrapping the auth+httprequest in a Nostr event adds extra overhead. Clearly it works, but figuring out auth via the existing JWT methods will allow for more services to use Nostr auth without customization.

Is this the spec we want for all "Nostr login" use cases?

@fiatjaf This suits my needs for web app login and server sessions. We can close #373

Nice NIP but I wonder why here there is no challenge need but NIP-42 required it? (NIP-42 became a lot less attractive after the challenge requirement)

On NIP-42 I suggested an authorization on connection with something like new WebSocket("wss://...?authorization=stringified_22242_event") (query string cause websocket doesn't play well with headers) but it got rejected because of #141 comment from @cameri .

I just implemented it in nostrcheck-api-ts it seems to me a very elegant solution to authenticate a request to a public API.

Thanks @v0l 🙂

Have we considered including notes for common HTTP request failure responses? Effectively returning 401 Unauthorised or 402 Payment Required would be reasonable to use - maybe others could be considered too.

For either of those responses, we could perhaps define a WWW-Authenticate header with a Nostr specific auth-scheme to indicate this method of auth is supported.

As an example:

WWW-Authenticate: <auth-scheme>
WWW-Authenticate: Nostr-NIP-98

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate
https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#authentication_schemes

I wonder the same, @arthurfranca.

I wonder the same, @arthurfranca.

Implementing a challenge in the authentication process can provide additional security, such as protection against replay attacks and ensuring request freshness, it may be overkill for the method described in NIP-98. Here are a few reasons why:

1. The method already includes several robust security measures, such as checking the kind, created_at, url, and method tags, which help ensure the authenticity and integrity of the request.

2. The use of a timestamp within the created_at tag, combined with the server's requirement to validate it within a reasonable time window, helps mitigate the risk of replay attacks without the need for a separate challenge.

3. The method is primarily designed for Nostr-specific HTTP services, which may have lower risk profiles than more general-purpose applications. In this context, the existing security measures might suffice.

4. Adding a challenge-response mechanism can introduce complexity and increase the time required for authentication. This might negatively impact the user experience and performance, especially if the benefits do not outweigh the added complexity.

While a challenge can provide additional security benefits, it may not be strictly necessary for the method described in NIP-98. The existing security measures appear sufficient to address the primary risks. However, if there is a need for enhanced security in the future, a challenge-response mechanism could be considered as an optional or additional feature.

@melvincarvalho do you understand why it is absolutely necessary for NIP-42 and not for this? I'm asking honestly because I forgot. For NIP-42 I think it wasn't just providing "extra security", it was absolutely necessary.

@fiatjaf as an example of prior work that includes a challenge, the lightning lud-04 spec includes a k value. Effectively making it an interactive protocol.

I just watched the Fedimint schnorr signature tech talk, and they mentioned it's possible to do this non-interactively where you effectively use a zero-knowledge proof (using a provably random number as I understand it) instead of a challenge/interactive protocol. I'm waiting for the slides to be posted, as I don't have a full description of how it functions.

For protocol based NIPs, if may be useful to include a diagram to make it clear. Something like this perhaps.

ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

The challenge is to avoid replay attacks. In NIP-42 an impostor can send an event created by someone else and the relay will believe the impostor is that someone else. In this NIP-98, an imposter can do the same thing (within the suggested 60 seconds).

Under normal usage impostors won't have access to the authenticating event. But in case they do through some other security weakness, it should only be usable once. This is for security-in-depth.

If an interactive protocol is intolerable, then we should be looking at zk-SNARK (although I'm not sure it provides the no-replay freshness guarantee we are looking for)

Under normal usage impostors won't have access to the authenticating event. But in case they do through some other security weakness, it should only be usable once. This is for security-in-depth.

I think I disagree here. Most authentication services have this problem. If you leak your JWT your have a problem until it expires. 60 seconds is much shorter than most token expiries.

And if most people consider this a problem, servers could store the id of the event, similar to how oath keeps track of used tokens, and forbid reuse. It would mean that the client will have to rebuild events for every subsequent request though, which sounds undesirable

The challenge is to avoid replay attacks. In NIP-42 an impostor can send an event created by someone else and the relay will believe the impostor is that someone else.

How? If the user Bob sends his event directly to the relay Ronald, and the event has a commitment to the relay URL, what can Ronald do with that? It can't use that to auth to other relays.

How? If the user Bob sends his event directly to the relay Ronald, and the event has a commitment to the relay URL, what can Ronald do with that? It can't use that to auth to other relays.

Ronald being the relay can't do anything interesting. But any 3rd party getting ahold of it could trick Ronald.

Should we change NIP-42 to remove the challenge? @mikedilger That would make it much simpler.

1. The method already includes several robust security measures, such as checking the kind, created_at, url, and method [...] help ensure the authenticity and integrity of the request.

Same as NIP-42.

2. The use of a timestamp within the created_at tag [...] within a reasonable time window

Same as NIP-42. (It is suggested 10 min but it could also be 60 seconds)

3. The method is primarily designed for Nostr-specific HTTP services, which may have lower risk profiles [...]

Relays (NIP-42 use-case) have even lower risk cause not only the auth event is signed, but all other payloads are signed events that a malicious client wouldn't be able to create without a nsec

4. Adding a challenge-response mechanism [...] negatively impact the user experience [...]

Totally agree! Also for NIP-42.

NIP-98 main difference is that on every request, a new auth event is created.
While on NIP-42 it is created just once, cause it is a persistent websocket connection.

To be clear, I'm in favor of not using a challenge for both NIPs. NIP-42 should be as easy as new WebSocket("wss://...?authorization=stringified_22242_event") -> close the socket if authentication fail -> or register pubkey to ws client instance

Should we change NIP-42 to remove the challenge? @mikedilger That would make it much simpler.

No. I'm not following your gist here. NIP-42 and NIP-98 need challenges.

The challenge in NIP-42 is needed. The attack is like this:

1. Bob connects to Ronald.
2. Ronald asks Bob for AUTH not requiring any challenge
3. Bob authenticates. But Eve was evesdropping and copied the auth event from bob.
4. Eve connects to Ronald.
5. Ronald asks Eve for AUTH not requiring any challenge
6. Eve presents the event that Bob generated. Ronald now thinks Eve is Bob.

Even with AUTH (but without wss) there is a session-hijacking attack where Eve can hijack the session and Ronald thinks he is continuing to talk with Bob, but it is now Eve. So NIP-42 should require WSS, not just WS.

Your concern is valid, and you've illustrated a potential vulnerability of a session-hijacking attack via eavesdropping, which is indeed a risk when not using a challenge-response authentication or not using a secure protocol such as WSS.

However, let me clarify that non-challenge signed headers can still be safe if implemented with proper measures. Here's how:

1. Using Secure Communication Channels: When the communication between the parties happens over secure channels like WSS (WebSocket Secure) instead of WS (WebSocket), the session is encrypted. So, even if Eve is eavesdropping, she won't be able to interpret the exchanged data, making it difficult to hijack the session.

2. Timestamping and Nonce: Adding a timestamp or a nonce (a number used once) in the authentication header could prevent replay attacks. Even if Eve captures Bob's authenticated event, she cannot reuse it because the timestamp or nonce will not be valid anymore.

3. Short-lived Tokens: The authentication event generated by Bob could include a short-lived token. Once the token expires, it cannot be used for authentication. This means that even if Eve captures the authentication event, she has a limited time to use it, reducing the window of opportunity for the attack.

4. IP Binding: The session could be bound to the IP address from which the original authentication event came. If Eve tries to use Bob's event, the IP address won't match, and the session won't be hijacked.

On idempotent operations like GET and PUT, non-challenge signed headers are generally safe because these operations can be performed multiple times without different outcomes.

Idempotency here means that making the same request once or multiple times results in the same state on the server. So, even if an attacker like Eve manages to replay Bob's request, it wouldn't lead to unintended consequences, as the state of the server would remain the same.

However, for non-idempotent operations like POST, where each request could lead to a different outcome (for instance, creating a new resource each time), the replay attack risk is significantly higher. In these cases, incorporating a nonce in your authentication protocol can help safeguard against such replay attacks.

When a client makes a request, it includes a unique nonce. The server keeps track of all used nonces and does not accept requests with nonces that have already been used. This way, even if Eve captures and attempts to replay Bob's request, the server would reject it because the nonce has already been used.

I agree that WSS prevents session hijacking.

I'm no fan of trusting in "short-lived". Eve can attack microseconds after. Anything the legitimate user could do, the attacker could do.

A nonce could work, but that means the server has to remember every nonce. If you think that is easier than the server issuing a challenge, then ok. But they have to be tracked forever, kind of like an ever growing blockchain. I should presume bitcoiners are fine with that craziness.

I hear you on idempotent operations. Replaying such is not a risk if they truly are fully idempotent.

IP binding isn't secure. Kevin Mitnick attacked Tsusomu Shimumora's lab using half-open TCP connections that spoofed the IP address... way back when I was learning computer security in 1994 or so.

A nonce could work, but that means the server has to remember every nonce. If you think that is easier than the server issuing a challenge, then ok. But they have to be tracked forever, kind of like an ever growing blockchain. I should presume bitcoiners are fine with that craziness.

It would only have to be kept until the timestamp goes out of the allowed timeframe

2. Timestamping and Nonce: Adding a timestamp or a nonce (a number used once) in the authentication header could prevent replay attacks.

A nonce could work, but that means the server has to remember every nonce.

The nonce is the event id. Just need to keep it around for the allowed time window (60 seconds).

IP binding isn't secure [...] Kevin Mitnick [...] spoofed the IP address [...]

For using the same ip on an http connection I only imagine it possible if using the same local network (like same lan house) or hacking the user ISP, but I'm not Kevin Mitnick xD. Atleast it is an extra security layer.

Regarding a NIP-42 version without challenge (NIP-98 doesn't need it as it is not a persistent session - just keep track of event id), the relay could do the AUTH command dance (the current NIP-42 with challenge) when something important is at stake.
Like when you are already logged in but have to send the current password again when wanting to change the password. For nostr it would be after user tries to do NIP-109: Pubkey Deletion, for instance. <- it doesnt even make sense cause attacker would need the nsec to create the event. so can't think of an use-case for challenge

So NIP-42 is overkill and has poor experience for the current use-cases (rate-limiting and [paid] relay login). For session creation, an authentication without challenge is good enough.

Another implementation with zapgate

This is interesting. I needed to create server-side events on behalf of users, and I solved a similar problem differently:

1. Client opens a websocket connection to the server.
2. Client uses a pubkey in the Authorization header when making an HTTP request.
3. The server does not immediately serve a response. It stalls.
4. Server pushes an event to sign to the client over the websocket.
5. Client signs the event and pushes it back to the server.
6. The server finally returns the HTTP response.

I have a very specific use-case (hacking Nostr support into a legacy system), but I thought you might think it's interesting.

Another possible flow uses NIP-07's encrypt functionality. The server has a pubkey, which at some point the client obtains and stores. The Authorization header contains the user's pubkey in plaintext, along with a signed message to the server's pubkey.

I've been thinking about this problem a lot.

I've drafted a protocol flow NIP for 401 Unauthorized and 402 Payment Required. I think it should become part of this NIP - as defining a protocol without clear lifecycle and having common uses defined, we will result in weird behaviours between implementations. https://gist.github.com/blakejakopovic/fe384b8fd97231ece267bf264eb466ef - feedback welcome.

I think the best way forward is to define optional additional security layers that can be used. One could be tracking event_id and limiting to single use. Another would be using certificate pinning inside your application, to prevent ssl stripping / MIM. Ultimately we need a non-interactive auth protocol, and optionally an interactive one if people so desire. You can always add additional security like in #469 (comment)

For an ephemeral event, the tag shouldn't matter as it's not going to be indexed anyway (u or url) - what we should do however is try define a standardised tag for urls going forward. However, really it's contextual anyway.

401 and 402 are a good idea, but I think it should be a separate NIP that builds on this one. Not every NIP-98 implementer will want to implement 402, and there are also numerous ways to do 402 that exist. Adding on 402 may be slow down merging of a NIP that has growing implementations.

How about extension of nip-98 as new nips 98x -- 980, 981, 982 etc.

@blakejakopovic I dont think they should be closely coupled. For example in NosDAV nip-98 is already implemented and i use it on an hourly basis

NosDAV is probably going to go in the direction of WebAccessControl and there are many standards for working with 401s 402s and 403s. Have a look for example as casbin.

Implementations that want only the login, should not be forced to take other optional items. But if they were presented as other NIPs they could be taken as needed. Implementations would be further ahead if this NIP were approved, and adding more things to it will push that time line out further.

Doesn't https://ucan.xyz/ basically do serverless JWT for authorization like we're looking at for this?

I implemented NIP-98 auth in Ditto: https://gitlab.com/soapbox-pub/ditto/-/blob/develop/src/middleware/auth98.ts

So you can call Mastodon API endpoints like GET https://ditto.pub/api/v1/accounts/verify_credentials with NIP-98 auth and it'll recognize you and return your Nostr account in Mastodon API format.

One idea which occurred to me... is that NIP-98 + proof of work is an epic combination for deterring spam and DDOS attacks. Nothing stops me from adding a NIP-13 nonce tag to auth events and then validating POW on the server.

You could use this during registration especially.

However, POW with NIP-07 is a bit awkward.

I implemented NIP-98 auth in a web component https://github.com/Dolu89/nostr-one
You can put this button on your website and it will call your login API. It's a web component. It's usable with any front-end framework and also on pure HTML/JS pages.

Then you can use NIP-98 from nostr-tools that I implemented too, in your backend to validate the event. https://github.com/nbd-wtf/nostr-tools/blob/3368e8c00e728ff9b4981d58f8f7e546caa1d0f1/nip98.ts#L63C23-L63C36
Documentation is probably not perfect. Don't hesitate if you don't understand something