Does NATS validate connect_opts.nkey before passing it to auth callout?

[evrys]

Hello! I am working on a leafnode architecture where I have an auth callout service that assigns permissions to individual leafnodes identified by an nkey. Leafnode config looks like this:

leafnodes {
    remotes = [
        {
          url: "wss://cloud.example.com:443/nats",
          nkey: "SUAOBBHEDFTZW3JXKCD7ZMSPHO5ZJX3L6IZS3OGEXK6CEY2IY23RF7XSME" # Some private key generated unique to each leafnode
        },
    ]
}

The auth callout service on the remote looks up a device id corresponding to the incoming public key in a database and returns JWT claims giving the leafnode permission to publish on e.g. devices.${id}.foo, which corresponds to an account export mapping on the leafnode side.

I observe that the auth callout service receives an object like this from NATS as part of the request claim:

{
  "nats": {
    "user_nkey": "UAO2CCMU37WL6VQGKZ6DRH52BCCUT7OWDBSTUIOT5W2KUI26YFSAPFNL",
    "connect_opts": {
      "nkey": "UDLY54Z6KSQXIP7SL4DICDB54FPYLX32NKZEIL5LDV3BUX327XTB4BLV",
      "lang": "nats.ws",
      "version": "3.2.0",
      "protocol": 1
    },
    "type": "authorization_request",
    "version": 2
  }
}

My question is: for nats.connect_opts.nkey specifically, can I assume NATS has already validated that the client is in possession of the corresponding private key by the time it reaches my code? Or do I need to implement some challenge-response mechanism on my end?

[aricart]

@evrys some questions:

• what are you using to implement your callout?
• how is the server configured for auth where the user is connecting?

IMHO you need to have the client give you want you want to auth on, don't depend on the server for that.

Also - callout doesn't do any kind of challenge response, you evaluate on what you got from the client, if you don't like it you reject, otherwise you issue a JWT for them - which is never given to them.

[evrys]

• The callout service is written in TypeScript using the various NATS libs, it's similar to this one https://github.com/sagemathinc/cocalc/blob/nats/src/packages/server/nats/auth/index.ts but a bit simpler
• The remote server is using the config example "for new setups" in the docs here https://docs.nats.io/running-a-nats-service/configuration/securing_nats/auth_callout#multiple-accounts

We're using auth callout because we need dynamic user permissions derived from the database, but I was hoping I could still lean on the nkey system a bit to establish identity since it's more secure than e.g. generating a long-lived token to give to the client (since the token would then exist in the database and be transmitted over the network, unlike the private nkey seed which is only ever on the client).

If the public key the callout service receives isn't already checked though I'll need to think of some other way to avoid it being spoofed, thanks!

[aricart]

@evrys you should take a look at https://github.com/synadia-io/callout.go, there are many checks that you should implement on your callout - the better suggestion is not to roll your own framework, but rather focus on the generation of your user jwt once you verified the data given by the client.

The implementation above is hardened, take a look at it.