NATS and Decentralized Security: A Modern Approach to Scalable Authentication

NATS and Decentralized Security

In an era with billions of connected devices and authentication requests scaling to millions per second, traditional centralized security models are reaching their limits. Synadia’s Bruno Baloi recently demonstrated how decentralized security models in NATS provide an elegant solution to these scalability challenges.

Check out the full webinar recording here or read on for the full recap, including a written version of the Q&A.

The Centralized Security Bottleneck

Traditional centralized security models work well for cloud-centric scenarios, e.g. e-commerce platforms or X where authentication requests are manageable. However, they begin to fail when faced with massive scale. For example, imagine millions of connected vehicles each requiring real-time authentication as they move around our physical world, crossing borders, losing and regaining connectivity, and more. The bottleneck isn’t just technical; it’s architectural.

Bruno suggests a paradigm shift: compartmentalizing security with regional security domains. This approach distributes the authentication load while maintaining security integrity, making it particularly relevant for IoT, connected vehicle, edge device, and other high-volume scenarios.

Domain-Driven Security: A New Paradigm

Drawing from domain-driven design (DDD) principles, Bruno introduces the concept of security domains—abstractions that encapsulate security logic and provide autonomy in managing tokens and authentication traffic within specific boundaries.

What makes NATS particularly powerful is its built-in support for decentralized security. Unlike traditional approaches that require complex gateway architectures and load balancers, with NATS, there’s a clear separation of concerns between security and your topology.

Authentication and authorization aren’t dictated by your topology. They’re overlays on top of your topology where you can define any kind of decentralized security model that you need using NATS operators, accounts, and users.

Two Approaches to Security Management

NATS supports two distinct models for security, each suited to different use cases:

1. The Operator Paradigm

Ideal for high-volume, high-frequency scenarios (e.g. high connection churn environments where many devices connect, disconnect, and reconnect frequently). The operator model creates a hierarchy of security where:

• The operator owns key signatures for signing underlying entities
• Hierarchical security structures can scale massively
• Automated key management reduces operational overhead

2. Configuration-Based Approach

Better suited for less dynamic environments or deployments with lower volumes of authentication traffic:

• File-based configuration for rapid testing
• Smaller account hierarchies
• Faster iteration cycles

The beauty of NATS lies in its flexibility—you can even use a hybrid approach where operators generate keys that are then managed through configuration files.

Secure Data Sharing Across Domains

One of NATS’ most powerful features is its account-based access control model. Accounts define natural security boundaries and enable precise control over what data can be shared and how.

NATS supports two primary data-sharing patterns across accounts:

Streams: Accounts can export subjects to allow clients in other accounts to subscribe to data. This enables secure, read-only access to published data from outside accounts.

Services: Accounts can export subjects to expose request/reply services, allowing clients in other accounts to send requests and receive responses—ideal for cross-account APIs or service endpoints.

Together, these features create a flexible, secure, and decentralized data flow model that supports complex organizational boundaries and use cases.

Bridging Centralized and Decentralized Worlds

Recognizing that many organizations can’t immediately abandon existing security infrastructure, NATS provides an elegant solution: auth callouts. This feature allows NATS to delegate authentication and authorization to existing security mechanisms including:

• IBM DC
• LDAP
• OAuth
• OIDC

This hybrid approach enables organizations to gradually transition to decentralized security while maintaining compatibility with legacy systems. For a deeper look at auth callout, check out the video below.

Q: What do you mean by “security domain”?

A: A “Security Domain” is an architectural construct used to describe the segregation of security responsibilities more clearly. We borrowed the term from Domain-Driven Design (DDD) to represent an encapsulation of security-related activities within a given context. From a design perspective, an Operator can loosely be associated with a Security Domain, although this is not a strict requirement.

Q: What are the differences between the NATS resolver and file vs. external (or is the term URL resolver)?

A: The resolver determines where the server loads JWTs for accounts and users. There are three types: 1) Memory resolver (for dev), 2) File resolver (loads from local files), and 3) URL resolver (fetches from an external HTTP endpoint). So yes, “URL resolver” is the correct term when referring to an external HTTP-based source of JWTs.

Q: We want the resolver external to our NATS cluster. Is that a separate NATS server that acts as a resolver?

A: No, the external URL resolver doesn’t require a separate NATS server. It refers to a service (e.g., HTTP API) the NATS server can query to fetch JWTs dynamically. A more recent option is the “Full Resolver,” where all servers in a cluster have built-in resolvers that communicate with each other to share information and perform lookups. This is known as the “mesh” resolver model. The URL resolver requires external logic and ongoing maintenance, whereas the Full Resolver is built into the core server and requires no additional components.

Q: In a cluster of 3 nodes using file-based auth, must the config file be synced across all nodes?

A: Yes. With file-based authentication, the relevant files must be updated on all three nodes, and each node must be restarted. If you use the Operator-based approach, updating an account on one node will automatically synchronize the changes with the other two.

Q: Is it possible to mix resolver-based JWT auth and config-based auth?

A: Typically no, as these are different authentication models. However, you can have a config file that uses nkeys instead of usernames and passwords. In that case, you can use the Operator model to generate the keys, while still relying on configuration files for server setup.

Q: Can a single NATS cluster support multiple Operators?

A: Yes, a NATS cluster can support multiple Operators. Whether you should do so depends on your system design and business domain requirements.

Q: Is there JWK support for JWT verification?

A: Verifying a JWT requires only the public portion of the signing key, which is safe to share with anyone who needs it. Account administrators can also create additional signing keys to delegate JWT signing or to rotate keys, allowing for bulk invalidation of previously signed credentials.

Q: How does authentication work at a leaf node? I currently use file-based config but want services to fetch credentials on startup.

A: Authentication works the same for leaf nodes and regular nodes. Each NATS server (including leaf nodes) can have its own auth model.

Clients connecting to a leaf node authenticate based on that node’s configuration, but cross-account requests (e.g., service imports) must be authorized at the hub/root as well. With the operator model, you can distribute account credentials using nsc, and clients can be configured to fetch them dynamically at startup.

Q: How do you get private keys to, for example, mobile devices where real users log in?

A: It depends on the implementation of the mobile client. One option is for the mobile agent to retrieve credential files from a remote repository via a common protocol (e.g., SCP, FTP), or even over NATS. Alternatively, the mobile client could listen on a system-specific subject to receive new credentials pushed to it.

Q: What do you mean by “push new credentials to the device directly”? Do you mean a JWT for authz after successful authentication?

A: Yes, though it would be a custom implementation. The device-side agent would need to listen for incoming credentials over NATS or poll an external source to retrieve them at startup.

Q: Can we currently manage operators and users via CLI only?

A: There is no standalone “nsc SDK” currently. However, the Synadia Control Plane (SCP) integrates nsc functionality into a UI, allowing you to create accounts, users, revoke tokens, etc., through the SCP interface.

Q: It looks like later versions of the NATS CLI have support for nats auth, e.g., nats auth --help. Is the plan for the NATS CLI to eventually replace nsc?

A: This has not been confirmed yet, but it’s likely in the longer term.

Q: Will third-party tooling become available to configure NATS servers (e.g., for multi-tenancy)?

A: Currently, NATS server command-line parameters allow you to define server configurations (e.g., routes, clustering). However, there’s no CLI to reconfigure a server post-launch. We’re considering building tooling for this in the future.

Q: NSC supports a CLI. Are there plans to offer SDKs as well?

A: Not at the moment. We’ve focused on providing a visual security management experience through the Control Plane, which uses nsc behind the scenes.

Q: Will the Control Plane be open sourced?

A: There are no current plans to open source the SCP.

Q: How would an external third party be authenticated if we want to grant them subscribe-only access to a topic?

A: You can create a dedicated Account for the third party and configure authentication via an Auth Callout. Within that Account, you can specify which users are allowed access to which subjects.

Q: Do you have Keycloak templates for Auth Callout?

A: Not at the moment.

Q: For the Auth Callout feature, is there a plan to define a plugin interface for common protocols like OIDC or SAML?

A: Yes, that is the plan.

Q: What are some advantages of using nsc + CLI over the Auth Callout method?

A: It’s not an all-or-nothing choice—NATS supports mixed models. You can use config-based authentication for known users and fall back to Auth Callout for others. This segregation happens at the Account level.

Q: So Auth Callout can be mixed with other auth mechanisms?

A: Yes—this is called “mixed mode.” But, you can’t mix Auth Callout and JWT auth within the same Account. You can however run a server with multiple Accounts, each using different auth mechanisms (e.g., one static, one callout, one resolver).

Q: How does credential rotation work while connections are live? Will existing connections be closed and forced to reconnect?

A: Yes. On rotation, clients are disconnected and must reconnect, at which point a new Auth Callout is invoked to provide updated credentials.

Q: For multi-tenancy, can tenants bring their own Auth Callout at a leaf node or cluster?

A: Yes. Leaf nodes can have their own Accounts, each configured with its own Auth Callout mechanism. For example, one leaf cluster might use a database-based Auth Callout, while another uses OAuth.

Q: Is Auth Callout a ready-made component I can use to integrate my IDM with NATS?

A: We’re working on quickstart templates to support this integration.

Q: Regarding auditability, is it possible for a consumer to identify the publisher, for writing to an application audit log?

A: This is not part of NATS’s core design, as publishers and subscribers are decoupled. However, workarounds exist. For instance, publishers can include a source_id in the message payload, which the consumer can parse and use to write to the appropriate audit log.

Still have questions about authn or authz in NATS? Get in touch with the NATS experts at Synadia.