JWT is used for authentication and authorization. In this article, I will explain everything you need to know theoretically to get started in using this in your next project. So without further ado let's jump right into the content. Happy reading!!!
Let’s kick off with some basic definitions of authorization and authentication, to get our hands dirty in security.
Authentication
Authentication is the process of verifying who we are, like while logging on to a PC with a user name and password or on to some websites, the PC or the website is basically checking whether we have an account on that particular PC or website, so that we can access their services.
Authorization
Authorization is the function of specifying access rights/privileges to resources, which is related to general information security and computer security and to access control in particular.
Generally speaking, it is the process of verifying whether we have access to do something, in particular, like read or write access to some root files on PC or changing password and username in websites, as these things are critically related to security.
JSON Web Token (JWT)
JWT is a token used to authenticate a user while logging in and authorizing a user while modifying some sensitive information like passwords, payments, and while accessing some protected routes in the app. JWT can be used in many programming languages like Python, JavaScript, Java, Go etc.
Structure of JWT
JSON Web Tokens consist of three parts separated by dots(.), which are
- Header
- Payload
- Signature
Therefore, a JWT looks like
xxxxx.yyyyy.zzzzz
Header
The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
For example:
Then, this JSON is Base64Url encoded to form the first part of the JWT.
Payload
The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
- Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims.
Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience), nbf (Not Before), iat (Issued At), jti (JWT ID).
Notice that the claim names are only three characters long as JWT is meant to be compact. (JWT Documentation)
- Public claims: Claim Names can be defined at will by those using JWTs. However, in order to prevent collisions, any new Claim Name should either be registered in the IANA “JSON Web Token Claims” registry or be a Public Name: a value that contains a Collision-Resistant Name.
In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Claim Name. - Private claims: A producer and consumer of a JWT may agree to use Claim Names that are Private Names: names that are not Registered Claim Names or Public Claim Names. Unlike Public Claim Names, Private Claim Names are subject to collision and should be used with caution.
An example payload could be:
The payload is then Base64Url encoded to form the second part of the JSON Web Token.
Do note that for signed tokens this information, though protected against tampering, is readable by anyone. Do not put secret information in the payload or header elements of a JWT unless it is encrypted. (JWT Documentation)
Signature
To create a signature we need a secret string, it could be anything but my advice is to use a longer word with a minimum of 15 characters, which shouldn’t be easy to guess. Then it will be Base64Url encoded and joined with the encoded header and encoded payload to create a signature.
For example, if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
The signature is used to verify the message wasn’t changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.
The following shows a JWT which has an encoded header, encoded payload and encoded secret string.
You can also use JWT debugger to get your hands dirty and to experiment with this concepts.
Working with JWT
Alright, all the theory part is over!
Now, I’ll give you a brief explanation of how and where we will use this in an application.
Two use cases of JWT is authentication and authorization, let’s look into that.
Authentication
When it comes to authentication, it is the sign up and log in part of an application. When a user creates an account for the first time, based on the credentials he gives, a JWT will be created with an expiration date and will be sent as a cookie to him, which will be stored in the browser of the client as a cookie. When the JWT expires it will be automatically deleted in the browser, this means the user is no longer logged in. So, in this part of authentication the JWT is not decrypted, it will be just created in the server and will be stored in the client browser as a cookie.
Authorization
When it comes to authorization, the application will check whether the requesting person has certain privileges to perform the requesting action.
For example, In our application say we have certain routes and actions which could be performed only by admins, then when a normal user tries to access that, his JWT will be decrypted and his role in the payload will be checked, if he is not an admin, his request will be denied.
Reference
That’s all. I hope you’ve learned something new. Have a Happy Day!!!
