How JSON Web Token (JWT) authentication works?

Tram Ho

1. What is JWT (JSON Web Token)?

  • JSON Web Token (JWT) is an open standard (RFC7519) to ensure the security of information transmitted between parties as JSON object.
  • This information is verifiable and reliable as it is a digital signature. Jwt can be registered using secret (with HMAC algorithm) or public / private key pair using RSA
  • It has a compact size: it can be sent via URL, POST parameter or inside the Header, its transmission is also very fast.
  • It is self-contained: payload contains all the information of the user, to avoid querying the database many times.
  • The purpose of using JWT is not to hide data but to ensure its authenticity.
  • JWT is a token-based stateless authentication mechanism. Since it is a client-side stateless session, the server does not have to completely rely on DataBase to store session information.

2. Architecture of JWT

  • A JSON Web Token consists of 3 parts separated by dots.


  • JWT header includes token type and algorithm for signature and encryption. The algorithm can be HMAC , SHA256 , RSA , HS256 or RS256 .


  • Payload includes session data called claim. Here are some of the standard permissions we can take advantage of:
  1. Issuer (iss)
  2. Subject (sub)
  3. Audience (aud)
  4. Expiratuib tine (exp)
  5. Issused at (iat)

We can customize the authorization so that we can. When custom confirmation permission is set.

  • Don’t put big data in claim groups. Claim kit must be compact.
  • Do not place sensitive information because JWT can be decoded easily.


  • The signature is used to verify that the JWT sender is the correct sender and to ensure the content has not been altered during submission between the parties.
  • To generate the signature, the header is encoded base64 and payload, along with a secret number and the signature algorithm specified in the header.

for example, if you are creating a token signature using the HMAC algorithm, SHA256:

  • The signature is the most important part of the JSON Web Token (JWT). The signature is computed by encrypting the header and payload using Base64url to encrypt and concatenate them with a separator. Then given the encryption algorithm.

So when the header or payload changes, the signature must recalculate. only the Identity Provider (IdP) has the private key to compute the signature to prevent token forgery

2. How does it work?

  • The way token-based authentication works is also quite simple. User enters his login information and sends it to serrver. If the credentials are correct, the server generates an encrypted token that is concurrent with the HMACSHA256 algorithm and also known as JSON Web Token (JWT). The client side will store and execute this code with subsequent requests to the server.
  • The server authenticates the user by taking the jwt sent from the client to decrypt and then compare it with the code in the database.

In authentication, when the user successfully logs in with the user’s registration information, the server side will return Jwt (the string called the token code). This code is encrypted

Since the token is authentic, great care should be taken to prevent security issues. In general you should not hold the token for long when it is not required.

  • You also should not store it in session or browser memory due to lack of security.
  • Whenever the user wants to access the routes it sends jwt, usually in the header for authorization using the Bearer schema. The header content is as follows:
  • This is a non-state authentication mechanism. Because the user status without alarms is stored in the server memory. Server routers will be protected. If the server checks that jwt in the header is valid, it will allow access. Since the jwt is self-contained, all the necessary information is available, reducing the need to query the database.
  • This allows for completely reliant on stateless data APIs and even making requests for services. It doesn’t matter which domains serve the API, since Cross-Origin Resource Sharing (CORS) is not used because cookies are not used.

3. Confidentiality

Like other authentication mechanisms, JWT also has its own advantages and disadvantages.

  • HTTPS must be used to ensure headers authentication.
  • Verify algorithm name explicitly. Not entirely based on an algorithm mentioned in the JWT’s header. There are a number of known header-based attacks such as the host without alias, header stripping.
  • Revoking user sessions from the server is very difficult. Since JWTs are set up to expire automatically, if an attacker gets the token before it expires, it leads to a variety of exploits. Building a token revocation list on your server to invalidate tokens is probably the best way to minimize it.
  • If JWT exists on cookies, we need to create HTTPOnly cookies. This will restrict the third party javascript to read the jwt token from cookies.
  • CSRF – If the JWT is still persisted on cookies, CSRF attacks could occur. We can mitigate the CSRF by using a special request and request header.
  • XSS – on the server side, you must always ensure that the data that the user creates is not yet potentially dangerous.

4. When should I use JWT

Here are some cases where JWT will be useful:

  • Authentication : This is a typical case of using JWT. Each time a user logs in, each subsequent request will include a JWT, allowing the user to access the accessible routes and resources with that token. Single sign-on is a widely used feature of JWTs today, with small cost of usage between systems with different domain names.
  • Information Exchange : A great way to securely pass information between parties, as they can be signed. For example, using public key / private key. You can be sure who the sender is. In addition, the signature is calculated using the header and payload you can verify that the content has not changed.

5. JWTs can be used in different ways:

  • Authentication: When a user successfully logs in with registration information, the token ID will be returned. According to the specification of OpenIDconnect (OIDC), the token ID is always JWT.
  • Authentication: After a user successfully logs in, the application can request access to other routes, services or resources (eg API) on that person’s behalf. To do so, every request it requires must have an access token, of the form JWT. Single Sign-on (SSO) widely uses JWT because of the small cost of the format and its ability to easily be used across different domains.
  • Information Exchange: A good yoke for securely transmitting information between parties because of signatures. means that you are sure the sender is exactly what they say.

Reference links :

Share the news now

Source : Viblo