What is JWT??
I’d like to share some insights into JSON Web Token (JWT) as I recently followed a tutorial to created an app based on Next.js. The tutorial (and my previous work experience) exposed me to the standard practice for handling user authentication involving the use of JWT.
A little intro to the JWT. According to jwt.io, JWT serves as a secure means of transmitting information between different parties through a digital signature. This versatile token can be used for either authentication purposes or simply for information exchange. The size of JWT is usually small, making them suitable for transmission via various methods such as through URLs, POST parameters in responses, or inside the HTTP header.
To further emphasize the advantages of JWT, AuthO provides valuable insights about benefit of using JWT compare to Simple Web Token (SWT) and Security Assertion Markup Language Tokens (SAML), which you can read here.
In Hitash’s Next.js tutorial, the process of generating and utilizing JWTs was thoroughly described, with example. He outlined the three main parts of an application, which, in a broader context, can serve as a baseline for system design: the user/browser, the api/controller, and the database. The interaction between these elements elements is shown when someone makes an API call to ‘user/verify’ (using GET method), the ‘verifyToken’ variable will be generated by API. This field will be duplicated and updated into the user’s database. At the same time, this value is sent to the browser as well (either through Response or Headers).
Upon token verification, the token is sent back to the API, either through either URL or request body. Once this token comes back, the system needs to locate where this token is stored in database. The response from database will return the associated user based on this token, which then is sent to API for verification status to be true. The app then grants the user to continue to access their account. It is crucial to set the token to have a predefined expiration time. That being said, every time a user logs into their account, the server generates a token, that will expire based on the time set. The code snippet below sets the expire time of the token to 1 day.
Additionally, Hitash explained about how ‘forgot password token’ operates the same way as ‘verify token’. When the API is called to request a password reset, it kicks off by generating a token. This token is then sent to the database and another copy is sent to the browser. The browser, then sends the token back to the API, prompting the API made a query to the database to retrieve the particular user with that token. Through this step, the user password will be updated.
Moreoever, understanding the structure of JWTs is essential. JWTs are made of three main parts: header, payload, and signature. If you have a JWT, you can decode it using base64 decoder. Note that these three parts of JWT is are separated by dot (.), with the first part representing the header, second part being the payload, and the third part indicating the signature. This dot-separated format ensures that JWT can be efficiently processed and verified.
When it comes to security considerations in generating and storing tokens, there are several things you need to consider. From a security standpoint, storing tokens in LocalStorage or SessionStorage can expose them to XSS attack. On the other hand, storing token in Cookies (with HttpOnly flag) can mitigate the XSS risk, but vulnerable to CSRF attack. This delves into the security topic. If you are interested in the security area, there is a wealth of information available on this web to through various different questions and discussions addressing these concerns.
In the next blog, I am going to write about how to restrict users from accessing different profiles if they are not authenticated. We can achieve this by using the middleware to enhance interoperability.
Happy learning!