JWT stands for JSON Web Token. 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 (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
JWT can have symmetric/asymmetric signatures for Signing. It is currently the latest standard for implementing Security in our web applications.
Flow, how it works with JWT:
- Each security tokens are protected data structures. it contains information about issuer, time of expiration of token, subject etc. These are identified under the claim section of JWT.
- Each JWT Token is signed, so its tamper proof and bears authenticity throughout its valid time frame.
- For accessing any resource, client requests for a token.
- Issuer issues a token to the client.
- Client makes use of that token when talking to resources. This token is generally placed in header of the request for consuming resource services.
When client wants to talk to resource, using a valid token in its header section of the request, resource can behave in two ways to serve the requests of clients:
1. By validating the token present in the request, which was provided to the client from the issuer or an Authentication Server. In this case, resource server has trust relationship with the issuer and it has also the information about encrypting standards used by the issuer. By making use of these information, resource validates the token and if the token if valid serves client with the sought services.
2. By sending the token received from the request to the Authentication-Authorization server. In this scenario, Issuer/Token-Validator is on the same server. It has responsibility to issue valid tokens to clients’ valid requests. It also does the task of validating the token sent by resource server. About the validity of token, the Authentication-Authorization server responds to resource server accordingly. Based on the output from Authentication-Authorization server, resource server can then process/reject the client requests.
We have developed an example application which implements JWT for Security, and goes by the second approach mentioned above. Each issues JWT token stays valid for 2 minutes and then expires. On using the same JWT token, resource server will reject the requests. Client needs to get the new token from Authentication-Authorization server. The token persists in a cookie at Client Side. In this approach all the logic of issuing the token and validating the token is present at only one place, that is at the Authentication-Authorization server end. If we have to scale up in a Dockerized environment, we can create as much instance of Authentication-Authorization server we want, and code wise everything related to authentication and authorization is present at only one place.
The demo project has:
- UI made in angular
- An authentication-authorization server.
- A resource server that is serving to requests made via web service calls.
Please find the link to GitHub repository below: