gogrlx/nats-server
1
0
Fork 0
mirror of https://github.com/gogrlx/nats-server.git synced 2026-04-02 03:38:42 -07:00
Code Issues Packages Projects Releases Wiki Activity

Mention protocol variances; fix typo

Browse Source
This commit is contained in:
Phil Pennock
2020-07-01 13:00:11 -04:00
parent 4bf3aa81ca
commit 644cc2b5be
1 changed files with 6 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
doc/adr/0005-jwt-authentication.md
View File

@@ -14,9 +14,11 @@ flow in a way which clients can safely handle. This architecture design note
provides for a check which clients can safely add now, to be compatible with
such future changes and to be proof against certain attacks.
Upon connection, the NATS server sends an `INFO` line with various fields; the
NATS client processes that, performs a TLS upgrade if appropriate, and then
sends a `CONNECT` line with various fields.
Upon connection, in classic mode the NATS server sends an `INFO` line with
various fields; the NATS client processes that, performs a TLS upgrade if
appropriate, and then sends a `CONNECT` line with various fields.
Some protocol variations adjust this (for websockets, for example) but this is
the core flow which all normal NATS protocol clients are expected to support.
At present, if a server supports JWT authentication then it generates a strong
random nonce, presented as the `nonce` field of the `INFO` line. If a client
@@ -29,7 +31,7 @@ contains the base64-encoded result of signing the nonce.
This protects the server against replay attacks, since a strongly random nonce
is chosen each time. It provides no inherent protection against
man-in-the-middle attacks, relying instead upon TLS checks. The server can
enforce mutual-TLS, but not all deployment scenarios encoforce this.
enforce mutual-TLS, but not all deployment scenarios enforce this.
A well-behaved client with a competent TLS stack, configured to only proceed
with TLS, will verify the NATS server's certificate before proceeding, so will