Authentication is the process by which the server identifies the user. For example, one user, 'John' can identify himself by giving his username and password, and the server will check if the given details are correct or not. Whereas authorization is the process to decide whether the given user has permission to perform some actions or access resources from the applications. It is like giving consent to someone to do some specific task. For example, a user 'John'(authenticated) has the permission to access a resource, but he doesn’t have the permission to create a resource.
JWT stands for JSON Web Token and is used for authorization for web applications. 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.
Usually, authorization is done using session. For example, you have a session ID that you send down in the browser's cookies, and then every-time the client makes a request, the server checks whether the session ID given by the user is there in the server's memory not. But, JWT, instead of using cookies, uses JSON Web Token to do the authorization.
In session-based authentication, the server has to remember the information, and whenever a request is made, it has to do a lookup to find the information. But, in JWT, all the data is stored in the token itself, and no information stored is in the server memory itself. And why is that great? You can then use the same token for multiple servers that you run without running into problems that one server has a piece of particular information, and the other server doesn’t.
This application of JWT is especially very useful in micro-services. In micro-services, multiple deployable products that are connected. Since there are various products, they all have their own individual servers. Now, in a session-based authorization, all the different servers must contain the user's information. So suppose three independent services are connected. The client makes a request to service two from the service one. The client has to re-enter all his details because the service two server doesn’t contain the information that service one server contains.
Whereas, in the case of JWT, if all the different servers share the same secret key, then a single JWT token can be used for authorization in all the various services. This makes JWT a handy tool for authorization purposes.
The three parts include:
The header consists of the main algorithm that the server uses to encode and decode the JWT token.
The payload consists of the data that is stored in the JWT token. The payload is then Base64Url encoded to form the second part of the JSON Web Token.
To create the signature part, you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. 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 confirm that the sender of the JWT is who it says it is.