Sharing RSA Public Key for decrypting JWT amongst Load Balanced servers
I’m trying to implement a cookie-less authentication mechanism for a web API that is stateless on the server (does not store session tokens) and can be load balanced across several servers.
I have implemented a JWT that gets returned to a client (mobile phonegap client) which gets stored in sessionStorage, and added to the header of post-authentication requests. While this works perfectly fine on a single server, I always want to have a standby server which can handle requests that initially authenticated on a different server. For this, I’m assuming that I will have to share keys amongst the different servers.
I don’t understand the security implications of moving public or private keys across servers. Is it completely unadvisable? If so, how can I meet my requirements? If not, are there standard methods for sharing keys? For example, a distributed config service like etcd? Manual ssh transfers? Is it more advisable to have a single server handling authentication, and then just share the public keys amongst the servers for decrypting the token for calls to the rest of the API?
Answer
If you don’t want to share keys AND you use asymmetric keys then you can key each server separately and have each server set a different iss (issuer) claim. Then the recipient of the JWT can “look up” the appropriate public key based on the iss claim. Our lookup was basically a config file that mapped the iss value to a file system location of the public key.
If you need to share secret keys then I’d look at key distribution techniques. A lot will depend on how much effort you want to put in.