What is the JWT ?

• JWT stands for JSON Web Token because its format is JSON and it is used as token in general.

• It has self-contained structure which means contents are embedded into JWT that we need as a JSON format. Contents can be verified and trusted because it is digitally signed with the help of keys and encryption algorithms which ensures the integrity of the token meaning that, we can be sure about of JWT wasn’t tampered or altered by someone.

• Thanks to its compact and lightweight structure, a JWT can be efficiently transmitted through various means such as URL parameters, POST requests, HTTP headers or cookies.

What is the purpose of usage of the JWT ?

• In general, the purpose of the using JWT is authorization but absolutely not authentication. Sometimes these are can be mixed up and it shouldn’t be done.

Authentication is proving yourself to the server like saying “that’s me” but authorization is saying something like “remember me ?”.

JWT can be obtained after the authentication and after that you can access the resources in the server with your ticket; yes it can be called as ticket like in cinema; firstly you need to log in the cinema system with your name and a couple of bucks and then you get access to cinema with your ticket after 1, 2 or 3 days later, if your ticket is not expired you can enter the cinema with your ticket.

In the same way after we logged in with our email and password -by the way it is authentication- then we get our token which is JWT apparently. After this process we can access the server resources with help of our token unit it expired.

• Also it can be used in exchanging of informations but it is not as popular as authorization is. When we do that, we can be sure the informations and JWT is valid and have not been altered because it is digitally signed as we discussed in “signature” and “introduction” parts. Beside signing, encryption should be considered in this context. Remember that, normally that’s up to you when you use JWT for authorization, but in this context it is different and you should keep your information secret because main idea is exchange some information

Let's Break It Into Its Parts

• Header

  • Let's start with the first part of the JWT, which is the "Header". It consists of two parts: the first one is the type of the token (typ), which is, obviously, JWT, and the second one is the algorithm used to sign the token (alg).

  {
     "typ" : "JWT",
     "alg" : "HS256"  
  }
  

  • A brief discussion on "alg": The encryption algorithm types mentioned in the first paragraph are actually indicated here. The type of algorithm is determined here; it can be either asymmetric or symmetric, and both have their own options. For instance, HS512 or HS256 might be options for a symmetric algorithm, while RS256 or ES512 could be options for an asymmetric algorithm.

• Payload

  • The second part of the JWT is the payload. It contains all data that we want to transmit, also known as "claims". There are three types of claims.
    • Registered Claims:
      • These claims are recommended but not compulsory. They are all predefined claims by JWT itself (RFC 7519); iss (issuer), sub (subject), aud (audience), exp (expiration time), iat (issued at), etc. Note that all the registered claims have only three letters, as does JWT, because it needs to be compact.
    • Public Claims:
      • These claims defined by you; such as username, email, and other important information, might be included. However, these are not custom claims; all of them are defined in sources such as the IANA JSON Web Token Registry or another URI that prevents collisions.
    • Private Claims:
      • Imagine that there is not such a thing like “myClaim” but you as a issuer and the other party as audience agree with that name to use and this is called private claim.

  {  
   "sub": "1234567890",  
   "name": "Sefa Kapısız",  
   "jti": "4b5fcea6-2a5e-4a9d-97f2-3d8631ea2c5a",  
   "iat": 1521191902,  
   "exp": 1521195630,
   "admin": true  
  }
  

• Signature

  • The last part of the JWT is the signature, and its primary purpose is ensuring the token's integrity. This is achieved through a combination of the header, payload, and the algorithm specified in the header, along with a secret key selected by the server. If any of these components are altered, the signature will change, allowing us to verify whether the JWT has been tampered with or not.
  • As I said signature is created with header and payload but of course it is not that simple. For the simple and fast understanding:
    • var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); Signature = AlgorithmWithinHeader(encodedString, 'secret');
  • As you see the whole point is combining base64 formats of header and payload with help of an algorithm and a secret which held by the server to verify tokens and sign new ones, simple is that.

Since we’ve seen all the processes of the parts of JWT we can create one of them with help of two base64 converting and two dots.

JWT = Base64Encode(Header).Base64Encode(Payload).Signature

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlNlZmEgS2FwxLFzxLF6IiwianRpIjoiNGI1ZmNlYTYtMmE1ZS00YTlkLTk3ZjItM2Q4NjMxZWEyYzVhIiwiaWF0IjoxNTIxMTkxOTAyLCJleHAiOjE1MjExOTU2MzAsImFkbWluIjp0cnVlfQ.6JDrXJ7aFP7a7-h87a-qs9TUrkE4eKauoIBc7hb20qA