Application Development: JWT approach in scalable microservices architecture
Microservices architecture [http://martinfowler.com/articles/microservices.html] is a mature robust Web Application Development approach are widely used among all web development platforms. It allows easy integration, deployment and horizontal scaling for VPS, pure cloud or dedicated hosting.
Generally, there would be several application instances runned on the same system or separated machines. User may connect or send request to any of front-end server and that transaction may be processed by any of instance of the next layer. That looks ok till we receive another request of the same user, which involves the result of previous transaction or an object specified for this case and this user. It’s called the state. And if it holds the state on specific instance, then the request have to be routed to that instance to be processed. Another approach is to share the state among all instances we have in the cluster. Both cases needs additional efforts for design, implementation and support. JWT provides a solution for this problem.
JSON Web Token (JWT) [https://jwt.io/introduction] is a standard for transferring information securely. There have to be small amount of data, but it’s signed, so, can be verified. There is HMAC with secret key stored securely on both parties, or RSA with pair of public and private keys may be applied. As JWT has small size, it can be widely used in Web Application Development for transferring signed information in POST parameters, Cookies, URL, HTTP Header.
The main application of JWT is an authentication scheme applicable for all type of Web Development platforms. Instead of putting session key into cookies, we generate a new GWT token with the user ID as a payload inside the token. In such way, there are both ability to check that the client is authenticated and actually know who is the user. If we have user ID right in the token for all the time of the session, then we don’t need to save that information (state) on the server at all. All needed data is in the token as a payload. Such scheme is the best solution for main horizontal scaling problem. It’s one of the key technologies for Stateless REST API implementations and microservices.
There is a plenty of ready-to-use modules to implement JWT in your project [https://jwt.io/#libraries]. Two key functions are token generation by payload and secret key, and token verifying. The result of successful login action would be a generation of the token and sending it back to the client. Basically, token may contain not just user ID, but some else commonly used data, as well, to skip getting that information from persistent storage all the time. E.g., department ID or role of user. All further request have to contain the token as an HTTP header Authorization: Bearer . The token is taken from the header and verified on the server side. As you can see, secret key is saved on server side only. Any token (even with empty payload) has its expiration time. That means a token is valid only specific period of time since it was generated. In case of capturing the token by a cracker, he can use it after that point. If server treated a token as an expired one, the user request would be un-authenticated. Good practice is to re-generate new valid token by existing one till last one is not expired yet. Such scheme allows us to have long enough sessions without re-login actions.