Cloud-Native Applications With JWT
Cloud-Native Applications With JWT
See what role JSON Web Tokens play in cloud-native development, including helping remove state from the equation for scaling as well as authentication and authorization.
Join the DZone community and get the full member experience.Join For Free
A cloud-native application is an application that is developed for a cloud computing environment.
There is no specific answer to the question, "What is a cloud-native application?" but rather there are different concepts that must be met.
One of the most important, in my opinion, is the ability to scale up and down at a rapid rate. And this means that our applications cannot have any state on the servers since, if one server goes down or is scaled down, then the state stored on that server will be lost.
This is very well summarized in this video, where it is explained with a shopping cart example. In a monolithic approach, you store the products of the shopping cart in a server session. If the server goes down, then all the products in the shopping cart are lost as well. In a cloud-native app, where server instances can be scaled up and down quickly, it is important not to have this stateful behavior in your services and design them to be stateless.
There are different approaches to achieve a stateless architecture, but they can be summarized into two categories:
- Using a distributed in-memory key/value data store like Infinispan.
- Using a token that acts as a session between the client and server — using, for example, JWTs.
In this post, I am going to introduce you the latter approach.
From the https://jwt.io/introduction/ site:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.
This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret using HMAC or a public/private key pair using RSA.
JSON Web Tokens consist of three Base64Url strings separated by dots which are: Header.Payload.Signature
So the idea basic idea for implementing stateless architecture on a backend using JWTs is:
- When the user adds the first product, the backend service generates a new JWT token with the product added and sends it back to the frontend.
- When the user adds a new product, it sends the product to add and also the JWT that was sent before by the backend.
- Then the backend verifies that the token has not been modified (verifying the signature), then it gets the products from the JWT payload added previously, adding the new one to the list. Finally, it creates a new token with previous and new products and sends it back to the frontend.
- The same process is repeated all the time.
So as you can see, now it is not necessary to maintain any state or add any new database service on the backend side, you just need to send the JWT back and forth with the products inside.
I have recorded a video of a simple shopping cart example where I show the stateless nature of the solution. It can be seen below:
Also if you want to check out the project that I used for recording you can take a look at my GitHub repo: https://github.com/lordofthejars/shop-jwt.
Notice that this is just a simple post so you can get the basic idea. But you need to take into consideration the following for production:
- Use HTTPS instead of HTTP
- JWT just signs the token. If you want extra protection apart from HTTPS, use JWE to encrypt the payload of the JWT as well.
- Fingerprint the token to avoid any man-in-the-middle attack and use these parameters as authentication parameters for the token.
- JWTs can be used for passing authentication and authorization as well.
You can watch my talk at JavaZone where I introduce some of these techniques:
The good part of JWT approach is that it simplifies the deployment of the service a lot. You don't need to deploy or configure any other distributed database to share the content across the cluster, which minimizes the problems related to the network for communicating to the distributed database or misconfiguring of any of the nodes.
The drawback is that the client needs to be aware and ready receive and send back the token. In the backend side, you need to sign and verify every token all the time.
Published at DZone with permission of Alex Soto , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.