JWT



A Quick Introduction to JWTs

JSON Web Tokens, often shortened with JWTs, are gathering more and more popularity in the Web environment. It is an open standard that allows transmitting data in JSON object, in a compact and secure way. They are usually used in authentication and information exchange scenarios, since the data transmitted between a source and a target are digitally signed so that they can be easily verified and trusted.

JWTs Structured
The JWTs are structured in three sections:

The Header: this is a JSON object containing meta-information about the type of JWT and hash algorithm used to encrypt the data.
The Payload: even this is a JSON object containing the actual data shared between source and target; these data are coded in claims, that is statements about an entity, typically the user.
The Signature: this section allows to verify the integrity of the data, since it represents a digital signature based on the previous two sections.

The three sections of a JWT are combined together into a sequence of Base64 strings separated by dots so that the data can be easily sent around in HTTP-based environments.
When used in authentication, JWT technology allows a client to store session data on its side and to provide the token to the server whenever it tries to access a protected resource.
Usually, the token is sent to the server in the Authorization HTTP header using the Bearer schema, and it should contain all the information that allows to grant or deny access to the resource.

Structure of JWT

It consists of three parts: Header, Payload, and Signature; all are separated by the dots(.).
So JWT looks like - "hhhhhhhhhh.ppppppppp.ssssssss".



How JWT works
 
As in authentication, after the user successfully logs in using their credentials, a JSON Web Token will be returned. The tokens are a way to authenticate the request, so we must care of the token to prevent security issues. The token is always to be sent with each request typically in the Authorization header using the Bearer schema.

Authorization: Bearer <<token>>  

This is a stateless authentication mechanism in which user state is never saved in server memory. The server route will check a valid JWT in Authorization header and if it is present, the user will be allowed to access protected resources. The JWT contains the all the necessary information.
 
Benefit of JWT over SWT and SAML token 

The JSON is less verbose than the XML. When JSON is encoded, its size is smaller than encoded XML data, so JWTis more compact than the SAML. This is the reason JWT is a good choice to be passed in HTML and HTTP environments.
 
SWT is asymmetrically signed by a shared secret using the HMAC algorithm. However, JWT and SAML can use a public/private key in the form of X.509 certificate for signing. Signing the XML with Digital Signature without introducing obscure security holes is very difficult. It is the very simplicity of signing JSON.
 
JSON is supported in most programming languages due to its quality of mapping directly to the objects whereas XML doesn't have a natural document-to-object mapping. So, it is easier to work with JWT than SAML token.

In next blog we will learn how to implement in ASP.NET CORE API

Comments

Popular Posts

How to position controls using Canvas control in WPF using MVVM

Change font and size in visual studio

DataGrid in WPF MVVM