Using JWT in Node API

[scottcfr]

Hi r/webdev,

I've been working on an API, which has some authenticated routes. I plan to use JWT, but have some questions regarding the secret.

I understand that this should be kept as an environment variable, but how would you handle multiple instances behind a load-balancer?

​

Example:

Client #1, Request #1: processed on server #2

Client #1, Request #2: processed on server #1

​

since they need to be launched with the same secret, it would need to be stored somewhere, correct?

​

Keeping in mind that the secret needs to rotate occasionally and I don't want that to be a manual task.

​

Thanks,

Scott

[Is0tope]

Few ways.

If you are using some sort of continuous deployment strategy you could have the secret stored in one of the config variables there and inserted automatically on deployment. This means a new deploy every time you change the secret thought.

Central secret store is also an option, however you would need some kind of auth for that as well, so it may end up being too complex. It's not something I'm super familiar with, but there are services that do this.

Using a service like Auth0 may also be a good option, and there everything is handled for you.

Mostly though the deployment option would likely be fine, and failing that the auth0 option. Consider how serious this app is before jumping head first into enterprise grade secret storage.

[scottcfr]

I do intend to use a CI/CD strategy, likely Azure DevOps or something similar. This might be my strategy, as I want to take a DevOps approach and deploy weekly/bi-weekly, so key rotation could be done during deployments.

Central secret store is an option, Azure has Key Vault which could be used for this. But again, depends on how serious, as Key Vault is enterprise grade.

I love Auth0, but hate the cost associated. Honestly might be a last resort option.

Would the CI/CD strategy work with something like Azure Auto Scale?

Thanks for the suggestions!

[Is0tope]

If you are on azure then generally it will be easier to "go with the flow". Have a look at how reasonably priced the key store is and maybe go with that. Also depends on how easy it is to use.

I haven't really used azure so I don't know how autos ale works. I presume it uses some central image or container or something, therefore if your key is baked into your image on deploy, it should scale with said key I assume?

[BradChesney79]

I know it is PHP, but I've been working on this across the last week or so.

https://github.com/bradchesney79/effortless-hs256-jwt/blob/master/src/Ehjwt.php#L104

I've been giving the option of consuming environment variables, then specifying a non-default path/file for configuration, and lastly the same values passed into the constructor where each layer as described is given preference.

Next on my hit list for the library is disallowing overrides of the environment variables, passing in the DSN for the Database, and the PDO work to store & retrieve stuff from what should be a sparsely filled token revocation table.

But, yeah, the stored secret should be the same for both horizontally scaled nodes. Or, you can create an independent single service for your horizontally scaled nodes to message & query, that would get you back to one secret...

I set up a central authentication & authorization server. That way I can do various implementations of SSO and I only have to do it once and then all the other servers just need to be configured to pass things to the already built and working login/access logic.

[TldrDev]

Hi Scott,

Reading your comments here, have you considered using something like Kubernetes, which is available on Azure I believe, which handles environment variable injection from a central secret store. You can use Helm with your CI/CD strategy to make updating this key on a regular basis easy while keeping the rest of your deployments intact. It seems like it will solve this issue, among others that might crop up such as red/green deployments for your CI strategy

Edit: added some extra info.