JWT Explained, Quick and Easy

JWT explained (JSON Web Tokens), in their simplest sense, are a way to send information. They’re a way to securely send information between two parties as a JSON object. Securely doesn’t mean it’s a method of transmitting confidential information. A JWT is meant to identify if someone is authorized to access a server. Therefore, the JSON object is shared between two authorized parties.

Each JWT contains a header, payload, and signature. All of which is encrypted using either HS256 or RS256. Covering these items and more is the goal of this post—JWT explained.

JWT Headers

The header contains meta data about the JSON Web Token. Meta data that may look like this for instance.

{"type": "jtw", "alg":"HS256"}

This is used so the resource server knows the encryption type. In turn, it can verify the signature. Again, a JWT contains the header, payload, and signature. So, the process moves in increments. Gather the data. Obtain the payload. Verify.

JWT Payload

The payload will contain user data in the form of key value pairs. It may contain role permissions and most definitely will contain an expiration date as well. A date in numeric format. Seconds since 1970 most likely. Or since the inception of the token. Upon the validity of the payload being verified, the user will gain access to a pre determined server. This is know as a resource server. And there can be many. Beyond JWT explained, you could mimic this behavior in a test environment.

There will most likely be additional properties in conjunction to the aforementioned. Properties such as the creation time of the JWT. And the issuing party. In debug for instance, this could be localhost. We as developers though could author whatever we see fit to signify it’s the authorization server.

JWT Signature

In this sample token below, notice the three parts denoted with a dot. The signature is the last part of the token.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded, we’d get the header, payload, and signature. Signatures can get pretty long. Length is important here to ensure they’re not tampered with. After the token is created and sent to the resource server, it’s recreated. The resource server does it’s own generation of thereof to ensure a match.

The Algorithm

The algorithm is a base64url encoded string of said items, separated by a dot. The premise here is to ensure nobody can replicate the data. The algorithm will also create a secret. One in which of course is only known to the servers involved in the protocol. This is to ensure an attacker cannot simply create an anomalous secret. If this does occur however, validation will fail.

More specifically, the base64url encoded version of the header is combined with the encoded payload. Separated by a dot. A secret is then appended. A hash is then created and used for transmission.

Conclusion

During my previous contract, I used JSON Web Tokens while working with PING. PING is a service that provides an Authorization Server, two factor authentication configuration, and provides a JWT to pipe into a bearer token. Used for client access. Users would enter their login credentials to be verified in a database. Upon which a JWT is returned, and the user is then sent to their desired destination (resource server 1). This was a .NET backend with an Angular UI.

I’ve also recently used it in a MEAN stack app (Mongo, Express, Angular, and Node). Upon the user entering their credentials, they were verified. Then a Node package generated an HS256 JWT. A JWT containing the users’ data.

• Read about more full stack development concepts here.
• Browse the entire category list and descriptions here.
• Check out an onslaught of JavaScript based projects here.

This was JWT explained. Hope you enjoyed it.