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 withS, stored in.nkfiles. Used by clients to prove identity. Never share this.Public key— starts withU(user),A(account), orO(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.