JS Questions: How are JSON Web Tokens Used?

This is the twelfth in a series of posts I’m writing that aims to provide concise, understandable answers to JavaScript-related questions, helping me better understand both foundational concepts and the changing landscape of language updates, frameworks, testing tools, etc.

How are JSON Web Tokens Used?

JSON web tokens (JWT) are a publicly-available system that enables secure transmissions between two parties. The technology is not JavaScript specific, but is useful in applications that must make verified requests to a server, such as a React front-end application requesting a user’s password-protected information through a fetch request. The JWT does not authenticate a user, but rather sends along the information needed to verify that the client making the request has been authenticated.

JTWs are popular for a few reasons. First, of all, because the tokens require a server-side decryption, they can’t be easily manipulated by the user or a third party. They’re also compact (preventing a bloated post request) and self-contained, meaning they don’t require a followup request for data after the authentication is made.

Here’s how a JWT might be used alongside the user authentication process to allow a client to access their password-protected information:

  1. A user enters their login information and their credentials are posted to a server. Upon confirming that the user has entered the proper information, a JWT can be created.
  2.  The JWT has three parts: 

Header: The header contains indication that it is a JTW token, as well as the type of hashing algorithm used, both stored in JSON format. A hashing algorithm is a type of function used to encrypt and decrypt data.

This header is base64 encoded, meaning that its data is locked in a format that won’t be modified in the transmission process. 

Payload: Also formatted in JSON, the payload contains the data being sent. This is where information such as a user’s id or unique username may be stored. This section can also store the token’s expiration date. 

The resulting JSON is base64 encoded.

Signature: This takes the encoded header and payload, as well as the algorithm indicated in the header, and a generated secret to create a signature.

Finally, the token can be created in the correct format: three parts separated by dots: header.payload.signature

3. The created JWT token is sent back to the client in the request’s response.

4. The token is stored in the client’s local browser storage so that it won’t be lost upon the page refreshing.

5. Every time the user requests information that is protected, the token is sent along in the header of the post request.

6. Each time the access token is sent with a request, it can be decoded using the secret stored on the server-side. No database query is needed to authenticate the request. The signature verifies that the token is coming from the right sender and that the data is not manipulated.

Note: I’ve referred to a secret key used to verify the token. The key is like a password that can be used to unlock private information. Just like a password, it can be changed and should be stored in a secure place. The HMAC algorithm uses a secret to encode and decode. RSA is another algorithm that uses public and private keys. Either system can be used with JWT. 


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s