Synadia Protect

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:

FileRoleDescription
admin.nkAPIadminister the gateway — manage bundles, traces, connections
system.nkSysteminternal system access
bundle-signer.nkBundle signersign 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:

FieldDescription
user_namebasic auth username
passwordbasic auth password
tokenbearer token
nkeyNKey seed (inline)
nkey_filepath to NKey seed file
jwtJWT credential (inline)
jwt_filepath to JWT file

See the Configuration Reference for details.