Decentralized JWT Authentication/Authorization

    Effectively, JWTs improve accounts and provide for a distributed configuration paradigm. Previously each user (or client) needed to be known and authorized a priori in the server’s configuration requiring an administrator to modify and update server configurations. These chores are eliminated. User creation can can even be performed by different entities altogether.

    JSON Web Tokens (JWT) are an open and industry standard method for representing claims securely between two parties.

    Claims are a fancy way of asserting information on a subject. In this context, a subject is the entity being described (not a messaging subject). Standard JWT claims are typically digitally signed and verified.

    NATS further restricts JWTs by requiring that JWTs be:

    • Digitally signed always and only using Ed25519.
    • NATS adopts the convention that all Issuer and Subject fields in a JWT claim must be a public .
    • Issuer and Subject must match specific roles depending on the claim NKeys.
    • Accounts
    • Users

    Roles are hierarchical and form a chain of trust. Operators issue Accounts which in turn issue Users. Servers trust specific Operators. If an account is issued by an operator that is trusted, account users are trusted.

    When a User connects to a server, it presents a JWT issued by its Account. The user proves its identity by signing a server-issued cryptographic challenge with its private key. The signature verification validates that the signature is attributable to the user’s public key. Next, the server retrieves the associated account JWT that issued the user. It verifies the User issuer matches the referenced account. Finally, the server checks that a trusted Operator - one the server is configured with - issued the Account, completing the trust chain verification.

    From an authorization point of view, the account provides information on messaging subjects that are imported from other accounts (including any ancillary related authorization) as well as messaging subjects exported to other accounts. Accounts can also bear limits, such as the maximum number of connections they may have. A user JWT can express restrictions on the messaging subjects to which it can publish or subscribe.

    When a new user is added to an account, the account configuration need not change, as each user can and should have its own user JWT that can be verified by simply resolving its parent account.

    One crucial detail to keep in mind is that while in other systems JWTs are used as sessions or proof of authentication, NATS JWTs are only used as configuration describing:

    • the public ID of the entity
    • the public ID of the entity that issued it

    The server is never aware of private keys but can verify that a signer or issuer indeed matches a specified or known public key.

    Lastly, all NATS JWTs (Operators, Accounts, Users and others) are expected to be signed using the algorithm. If they are not, they are rejected by the system.

    Configuration is broken up into separate steps. Depending on organizational needs these are performed by the same or different entities.

    JWT configuration is done using the tool. It can be set up to issue and corresponding JWTs for all nkey roles: Operator/Account/User (). Despite Account and User creation not happening in server configuration, this model is a centralized authentication and authorization setup.

    Provided institutional trust, it is also possible to use nsc to import account or user public NKeys and issue corresponding JWTs. This way an operator can issue account JWTs and a separate entity can issue JWTs for user associated with it’s account. Neither entity has to be aware of the other’s private Nkey. This not only allows users to be configured some place other than servers, but also by different organizations altogether. Say administrators of a NATS installation controlling operators, issuing account JWTs to individual prod/dev teams managing their own user. This is a fully decentralized authorization setup!

    It is possible to JWT and NKEY/ based Authentication/Authorization.