JWT Stands For...

Intro to JWT

JWT stands for JSON Web Token*. JWTs are JSON objects that allow for secure transmission of information.

JWTs are made up of 3 components that are separated by periods. The 3 components are:

• Header
• Payload
• Signature

Each component in the JWT is encoded using Base64Url (check out this article for more information on Base64Url encoding). An example of a Base64Url encoded JWT is shown below.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

//note the dots separating each string of characters

The header of a JWT contains the type of token (JWT) and the algorithm used for signing the token. Below is an example of the type of information contained in the header.

{ "typ": "JWT", "alg": "HS256" }
//HS256 is short for HMAC-SHA256

There are 3 types of signing algorithms that you might see:

• HMAC (Hash-based Message Authentication Code)
  • Uses cryptographic hash function and a secret cryptographic key - Wikipedia Article on HMAC
• RSA (Rivest–Shamir–Adleman)
  • Asymmetric (there are two different keys) cryptographic algorithm - Wikipedia Article on RSA
• ECDSA (Elliptic Curve Digital Signature Algorithm)
  • Variant of DSA (Digital Signature Algorithm) - Wikipedia Article on ECDSA

The payload of a JWT is where you might find information about a user.

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. - JWT Docs

Be careful not to include any unencrypted secret information in the payload! You can use a gem like BCrpyt (Wikipedia Article on BCrypt) to encode password information.

The signature of the JWT verifies that the token hasn't been changed and looks at any private claims in the payload to verify that the sender of the token is who it claims to be. The signature is calculated using the header and the payload.

Check out JWT's Debugger Tool to "decode, verify, and generate JWT"

JWT in Action

JWT is commonly used for authorization. After a successful login the server returns a JWT that can be used to verify the user when they want to access protected routes. You can store the token in browser storage or cookies and there are trade-offs with either.

• If you want to read more about why you might choose to store JWTs in one place versus the other, you can read this article on where to store JWTs by Tom Abbott and this blurb about local storage from OWASP.

When a user wants to access a protected route the JWT can be sent for verification using an authorization header using the "bearer schema".

'Authorization': 'Bearer <token>'

Bearer authentication (also called token authentication) is an HTTP authentication scheme that involves security tokens called bearer tokens. The name “Bearer authentication” can be understood as “give access to the bearer of this token.”Swagger.io Docs - Bearer Authentication

Once the token is sent back to the server it can be validated - if the token is valid the user will be able to access the protected route.

In Conclusion...

JWT is a great option for implementing authorization. Using JWT you can authorize a user and be certain that their credentials haven't been tampered with (thanks to the header, payload, signature combination!). This was just a quick introduction to JWT and there is so much more to cover, but don't you worry, there's plenty more great places all over this internet. I'll be looking for you next time, on Desktops, Dev.to's, and Drives!

Resources:

• JWT.io Docs
• JWT's Debugger Tool
• Ruby JWT Docs
• Base64Url Article by Brock Allen
• Where to Store your JWTs – Cookies vs HTML5 Web Storage by Tom Abbott
• OWASP HTML5 Security Cheat Sheet - Local Storage
• Swagger.io Docs - Bearer Authentication
• Wikipedia!

*If you made it this far, then I have to tell you something. I lied. JWT does not stand for JSON Web Token. JWT stands for Jonathan Webtaylor Thomas.