I\'m trying to implement a cookie-less authentication mechanism for a web API th
ID: 658484 • Letter: I
Question
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?
Explanation / 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.