From c80be21cd44aa74efa42ead23a12343bf33ade34 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 2 Jan 2023 16:49:37 -0300 Subject: drastically simplify @semisol's auth NIP. --- 42.md | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 42.md (limited to '42.md') diff --git a/42.md b/42.md new file mode 100644 index 0000000..d5122ba --- /dev/null +++ b/42.md @@ -0,0 +1,68 @@ +NIP-42 +====== + +Authentication of clients to relays +----------------------------------- + +`draft` `optional` `author:Semisol` `author:fiatjaf` + +This NIP defines a way for clients to authenticate to relays by signing an ephemeral event. + +## Motivation + +A relay may want to require clients to authenticate to access restricted resources. For example, + + - A relay may request payment or other forms of whitelisting to publish events -- this can naïvely be achieved by limiting publication + to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an + authenticated user; + - A relay may limit access to `kind: 4` DMs to only the parties involved in the chat exchange, and for that it may require authentication + before clients can query for that kind. + - A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication. + +## Protocol flow + +This NIP defines a new message, `AUTH`, which clients can send to relays when they want to authenticate. The message is of the following form: + +``` +["AUTH", ] +``` + +The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and content must be set to the +WebSocket URL of the relay. `created_at` should be the current time. Example: + +```json +{ + "id": "...", + "pubkey": "...", + "created_at": 1669695536, + "kind": 22242, + "tags": [], + "content": "wss://relay.example.com/", + "sig": "..." +} +``` + +The client may send an auth message right before performing an action for which it knows authentication will be required -- for example, right +before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. + +Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For +that it can use a `NOTICE` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: + +``` +["NOTICE", "restricted: we can't serve DMs to unauthenticated users, does your client implement NIP-42?"] +``` + +or + +``` +["NOTICE", "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] +``` + +## Signed Event Verification + +To verify `AUTH` messages, relays must ensure: + + - that the `kind` is `22242` + - that the event was recently signed (~10 minutes, by `created_at`) + - that the `content` field matches the relay URL + - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough. -- cgit v1.2.3 From 4a5202646a86ce63a85a50b560d1a2fbce277df6 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Mon, 2 Jan 2023 17:26:41 -0300 Subject: use "OK" message. --- 42.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to '42.md') diff --git a/42.md b/42.md index d5122ba..b17aa14 100644 --- a/42.md +++ b/42.md @@ -52,10 +52,10 @@ that it can use a `NOTICE` message with a standard prefix `"restricted: "` that ["NOTICE", "restricted: we can't serve DMs to unauthenticated users, does your client implement NIP-42?"] ``` -or +or it can return an `OK` message noting the reason an event was not written using the same prefix: ``` -["NOTICE", "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] +["OK", "b1a649ebe8...", false, "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] ``` ## Signed Event Verification -- cgit v1.2.3 From 50faceef0965042714e7f50a45b102f35c5231ca Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 4 Jan 2023 10:24:37 -0300 Subject: clarify `created_at` and auth session duration. --- 42.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to '42.md') diff --git a/42.md b/42.md index b17aa14..4c884a9 100644 --- a/42.md +++ b/42.md @@ -43,7 +43,8 @@ WebSocket URL of the relay. `created_at` should be the current time. Example: ``` The client may send an auth message right before performing an action for which it knows authentication will be required -- for example, right -before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. +before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. The authentication +is expected to last for the duration of the WebSocket connection. Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For that it can use a `NOTICE` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: @@ -62,7 +63,7 @@ or it can return an `OK` message noting the reason an event was not written usin To verify `AUTH` messages, relays must ensure: - - that the `kind` is `22242` - - that the event was recently signed (~10 minutes, by `created_at`) - - that the `content` field matches the relay URL + - that the `kind` is `22242`; + - that the event `created_at` is close (e.g. within ~10 minutes) of the current time; + - that the `content` field matches the relay URL: - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough. -- cgit v1.2.3 From 6a70967f0eb6e7b00fc811e34631f8db046d6e1f Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Sat, 7 Jan 2023 19:53:42 -0300 Subject: add challenge from relay. --- 42.md | 37 +++++++++++++++++++++++++++---------- README.md | 1 + 2 files changed, 28 insertions(+), 10 deletions(-) (limited to '42.md') diff --git a/42.md b/42.md index 4c884a9..93bb3e3 100644 --- a/42.md +++ b/42.md @@ -19,16 +19,23 @@ A relay may want to require clients to authenticate to access restricted resourc before clients can query for that kind. - A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication. -## Protocol flow +## Definitions + +This NIP defines a new message, `AUTH`, which relays can send when they support authentication and clients can send to relays when they want +to authenticate. When sent by relays, the message is of the following form: + +``` +["AUTH", ] +``` -This NIP defines a new message, `AUTH`, which clients can send to relays when they want to authenticate. The message is of the following form: +And, when sent by clients, of the following form: ``` -["AUTH", ] +["AUTH", ] ``` -The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and content must be set to the -WebSocket URL of the relay. `created_at` should be the current time. Example: +The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and it should have at least two tags, +one for the relay URL and one for the challenge string as received from the relay. `created_at` should be the current time. Example: ```json { @@ -36,18 +43,27 @@ WebSocket URL of the relay. `created_at` should be the current time. Example: "pubkey": "...", "created_at": 1669695536, "kind": 22242, - "tags": [], - "content": "wss://relay.example.com/", + "tags": [ + ["relay", "wss://relay.example.com/"], + ["challenge", "challengestringhere"] + ], + "content": "", "sig": "..." } ``` +## Protocol flow + +At any moment the relay may send an `AUTH` message to the client containing a challenge. After receiving that the client may decide to +authenticate itself or not. The challenge is expected to be valid for the duration of the connection or until a next challenge is sent by +the relay. + The client may send an auth message right before performing an action for which it knows authentication will be required -- for example, right before requesting `kind: 4` chat messages --, or it may do right on connection start or at some other moment it deems best. The authentication is expected to last for the duration of the WebSocket connection. Upon receiving a message from an unauthenticated user it can't fulfill without authentication, a relay may choose to notify the client. For -that it can use a `NOTICE` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: +that it can use a `NOTICE` or `OK` message with a standard prefix `"restricted: "` that is readable both by humans and machines, for example: ``` ["NOTICE", "restricted: we can't serve DMs to unauthenticated users, does your client implement NIP-42?"] @@ -56,7 +72,7 @@ that it can use a `NOTICE` message with a standard prefix `"restricted: "` that or it can return an `OK` message noting the reason an event was not written using the same prefix: ``` -["OK", "b1a649ebe8...", false, "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] +["OK", , false, "restricted: we do not accept events from unauthenticated users, please sign up at https://example.com/"] ``` ## Signed Event Verification @@ -65,5 +81,6 @@ To verify `AUTH` messages, relays must ensure: - that the `kind` is `22242`; - that the event `created_at` is close (e.g. within ~10 minutes) of the current time; - - that the `content` field matches the relay URL: + - that the `"challenge"` tag matches the challenge sent before; + - that the `"relay"` tag matches the relay URL: - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough. diff --git a/README.md b/README.md index f627f4d..05737b1 100644 --- a/README.md +++ b/README.md @@ -70,6 +70,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | NOTICE | used to send human-readable messages to clients | [1](01.md) | | EOSE | used to notify clients all stored events have been sent | [15](15.md) | | OK | used to notify clients if an EVENT was successuful | [20](20.md) | +| AUTH | used to send authentication challenges | [42](42.md) | Please update these lists when proposing NIPs introducing new event kinds. -- cgit v1.2.3 From 60741160535de8137fb7a74bd6561adef974b884 Mon Sep 17 00:00:00 2001 From: Leo Wandersleb Date: Wed, 11 Jan 2023 00:05:15 -0300 Subject: Update 42.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Ricardo Arturo Cabral Mejía --- 42.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to '42.md') diff --git a/42.md b/42.md index 93bb3e3..9b0c45b 100644 --- a/42.md +++ b/42.md @@ -35,7 +35,9 @@ And, when sent by clients, of the following form: ``` The signed event is an ephemeral event not meant to be published or queried, it must be of `kind: 22242` and it should have at least two tags, -one for the relay URL and one for the challenge string as received from the relay. `created_at` should be the current time. Example: +one for the relay URL and one for the challenge string as received from the relay. +Relays MUST exclude `kind: 22242` events from being broadcasted to any client. +`created_at` should be the current time. Example: ```json { -- cgit v1.2.3