Point of the .jwt and .nk files generated by nsc?

[Mike Cardwell]

I'm using jwt's for authentication, and I'm generating them using the nsc command. I'm pushing the account JWT's to my nats server. When I generate a user, three files are created:

.jwt

.nk

.creds

It's my understanding that the .creds file contains the .jwt and the .nk (private key). I give the .creds file to the client so it can log in.

My question is, what is the point of the .nk and .jwt files existing for a user? If both of those pieces of data are already stored inside the .creds file, why bother keeping duplicate copies of it in the .jwt and .nk files? Couldn't nsc just read the .creds file whenever it needs access to either of those pieces of data?

The reason I'm asking is because of internal discussion re what we should be storing in git. I'm storing all of these files at the moment, but making sure that the .nk and .creds files are encrypted with gitcrypt as they are sensitive. The .jwt file isn't encrypted because to my understanding it doesn't contain any secret data. But yeah, I don't know why we even need this file (for users) if it's not distributed to the server or the client at any point, and nsc could get it's contents from the .creds file instead.

Red Sift is a limited company registered in England and Wales. Registered number: 09240956. Registered office: 3rd Floor, 1 Ashley Road, Altrincham, Cheshire, WA14 2DT.

[Alberto Ricart]

The creds files are an artifact with secrets, the others are the actual config, and the state of the config for the user. Pub/sub permissions, etc.

Depending on your strategy, you can choose to throw them away or not If you ever need to revoke, you'll need the user public key, unless you want to revoke at a higher level (ie all JWTs issued since some day or all JWTs issued by a signing key). You can absolutely try to import a creds to recover the user. 

In Git you should store all the JWTs for operator and accounts at a minimum. If you use bearer user JWTs treat those as secrets as well since they don't require an NKEY to authenticate. 

In the end, what you preserve is a matter of what you'll need to restore your environment. With the new state of the arts (latest server versions) it is possible to create an auth callout, and simply generate user NATS credentials whenever the user connect by inspecting other data that the user provides (token, username, IP, etc). This means that code is used to on-board the user and generate permissions for that user on every connect.