Authentication

NKeys

NKeys are a public key infrastructure (PKI) based on Ed25519 keypairs, used for authentication in NATS and Synadia Protect. Unlike passwords or tokens, NKeys use challenge-response authentication — the private key never leaves the client.

The key prefix indicates its role. Each NKey has two parts:

• Seed (private key) — starts with S, stored in .nk files. Used by clients to prove identity. Never share this.
• Public key — starts with U (user), A (account), or O (operator). Placed in configuration to authorize access.

The seed and public key are mathematically linked — the public key can be derived from the seed, but not the reverse. Authentication works by signing a challenge with the seed; the server verifies the signature using the public key.

NKeys are stateless — there is no server-side session, token expiry, or revocation protocol. To revoke access, remove the public key from the configuration and restart the gateway.

Standalone gateway authentication

Standalone gateways use NKey authentication exclusively. The protect setup command generates three keypairs:

File	Role	Description
admin.nk	API	administer the gateway — manage bundles, traces, connections
system.nk	System	internal system access
bundle-signer.nk	Bundle signer	sign bundles for tamper-proof installation

The gateway configuration stores the public keys for each role:

management:
  api_key:
    - UBZ4SGUAFFUBHNNZJ6K76SWRGC7TE7XIFMRDFHGZHTCQ2BB23FZG42L6 # public key from admin.nk
  system_key:
    - UD6MMRSS6DFTSXHVSV3TYELESX2E2VMCKV6XMKHIILTOXN7IZ2GQG3SY # public key from system.nk

The trusted_bundle_signers in the rules section lists public keys authorized to sign bundles:

rules:
  trusted_bundle_signers:
    - UDHLNCKJRIFWS4QYOMMN4EPB7UIMIHDHXSRYSDOTDW4LPDDIV3IYXSOT # public key from bundle-signer.nk

Multiple public keys can be listed in each role — this allows multiple administrators, systems, or bundle signers. To revoke access, remove the public key and restart the gateway.

Admin CLI and NATS contexts

The protect admin commands connect to the gateway's management API. Rather than passing credentials on every command, use NATS contexts:

$ nats context add --server 127.0.0.1:4911 --nkey admin.nk admin
$ protect admin --context admin info

A context stores the server URL and credentials in a reusable profile. The --context flag selects which context to use.

Configuration server authentication

Configuration servers connect to an external NATS cluster. They use whatever credentials the cluster requires — username/password, NKeys, or JWTs:

configuration_server:
  urls:
    - nats://127.0.0.1:4222
  api_credentials:
    user_name: api
    password: api
  data_credentials:
    user_name: data
    password: data

The protect admin commands and the protect UI connect to the external NATS cluster using the API account credentials. Create a context matching the cluster's auth method:

# username/password
$ nats context add --server 127.0.0.1:4222 --user api --password api config-admin

# NKey
$ nats context add --server 127.0.0.1:4222 --nkey api.nk config-admin

# JWT + NKey
$ nats context add --server 127.0.0.1:4222 --creds api.creds config-admin

Managed gateway authentication

Managed gateways use NKey authentication for their embedded management API (same as standalone). They connect to the external NATS cluster using only DATA account credentials:

remote_configuration_server:
  urls:
    - nats://127.0.0.1:4222
  data_credentials:
    user_name: data
    password: data

To administer a managed gateway directly, connect to its embedded management API using the admin NKey — same as a standalone gateway.

Credential types

All credential fields in the configuration support these formats:

Field	Description
user_name	basic auth username
password	basic auth password
token	bearer token
nkey	NKey seed (inline)
nkey_file	path to NKey seed file
jwt	JWT credential (inline)
jwt_file	path to JWT file

See the Configuration Reference for details.