konnect Issue-date: 30th September 2020.




Name: Rishabh Taparia
ISA Member Number: 000033822832


Authentication & Authorization in Web Applications

Over the years, web applications have become more and more powerful with many exciting frameworks and tools developing and making the User experience better, day by day. But as we focus on the user experience, has application security also kept up? In the following article, we would look at how authorization of the users takes place in web applications.

Authorization and Authentication:

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.

What is JWT?

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.

Why should you use JWT?

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.

The above image shows how a session-based authentication works. The user sends the login details to the server, to which the server sends a unique session id in the form of cookies to the user. While making an authentication request, the user sends the session id to the server, and then the server checks the id in its memory and sends the user the required details. In the case of JWT, when the server receives a request, instead of storing the session data in memory, the server returns a token, which serializes (encode) and signs with its own secret key. In this way, the server knows that it is invalid if you tamper with the private key. The server sends the JWT token to the browser and doesn’t store anything on its memory. The browser then holds the token in any suitable form (example cookies), and while making an authentication request, sends the token to the server. The server verifies the JWT signature and get the user from the token and then sends the appropriate response back to the browser. The below image shows the entire process.

The primary difference between Session and Token-based 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.

Structure of a JWT Token:

JWT consists of three main parts, each separated by a “.” (dot).

The three parts include:

  • 1. Header
  • 2. Payload
  • 3. Signature

Header:

The header consists of the main algorithm that the server uses to encode and decode the JWT token.

Payload:

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.

Signature:

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.

In its entirety, the JSON Web Token looks something like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.cThIIoDvwdueQB468K5xDc5633seEFoqwxjF_xSJyQQ

The Decoded version of the JWT looks something like this:

So, this is how a JWT token works. It is a new technology that solves a lot of the problems that the session based authentication system had.