NATS supports a shared token, user and password, NKeys, TLS client certificates and decentralized JWT. For anything beyond a lab, prefer NKeys, certificates or JWT over a shared token, store passwords as bcrypt hashes, run TLS, and never start a server with no authorization block.
The options
The NATS documentation describes these methods.
- Token: one shared secret in the authorization block, server wide, with no username. The docs call it usable for quick internal setups but little else.
- User and password: each user has a name and password, which can be plaintext or bcrypt hashed.
- NKey: the server config holds only a public key. The client signs a server-issued nonce with its private seed, so the secret never crosses the wire.
- TLS client certificates: the server maps a certificate identity to a user, so the certificate is the credential.
- JWT, decentralized authentication: covered on separate pages about operator mode, aimed at many tenants and dynamic users.
How to pick
Think about how many identities you have and how often they change.
- A handful of services and a slow rate of change: NKeys or certificates in a central config file.
- Dozens of teams or tenants, accounts that come and go: decentralized JWT with operator mode, so you are not editing one config for everyone.
- Quick local development only: a token, and never carry it forward.
Passwords have two weak spots
The documentation shows the server warning about plaintext passwords and suggesting nkeys or bcrypt. Bcrypt protects the config file at rest, but not the credential in transit, so pair passwords with TLS. A hashed password sent over plain TCP is still a captured password.
The empty config trap
An unconfigured server admits every connection, as the documentation implies. Make "authorization block present" a deployment check. In a managed environment, add a test that tries to connect without credentials and expects a refusal.
Authentication is half the job
Authentication decides which user a connection is. Authorization decides what that user may publish or subscribe to. Plan subject permissions per service: a producer may publish to its subjects only, and a consumer may subscribe only to what it consumes. The NATS authorization page covers the syntax, so read it before you finalize naming. A subject naming scheme that groups by owning service makes permissions short and reviewable.
Compare with other brokers
The same questions appear in every broker: who can connect, who can publish, who can read. See how Kafka SASL mechanisms compare and the RabbitMQ mechanism list.
Safeguard can help here in a small way. Its SBOM and dependency scanning covers the broker client libraries and service frameworks your code pulls in, and reachability analysis shows which advisories your services actually call. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a NATS token good enough for production?
It is one shared secret for every client, so a leak affects all of them and you cannot tell clients apart. Prefer per identity credentials.
Do NKeys need TLS?
The secret never crosses the wire, but TLS still protects message content and server identity. Run both.
Sources
Last reviewed: 19 October 2026.
