September 2, 2019

2031 words 10 mins read



:closed_lock_with_key: Learn how to use JSON Web Token (JWT) to secure your next Web App! (Tutorial/Example with Tests!!)

repo name dwyl/learn-json-web-tokens
repo link
language JavaScript
size (curr.) 130 kB
stars (curr.) 4059
created 2015-01-29
license MIT License

JWT logo wider

Learn how to use JSON Web Tokens (JWT) for Authentication

dilbert fixed the internet

Learn how to use JSON Web Token (JWT) to secure your Web and/or Mobile Application!

Build Status codeclimate-maintainability Dependencies Status devDependencies Status contributions welcome HitCount


JSON Web Tokens (JWTs) make it easy to send read-only signedclaims” between services (both internal and external to your app/site). Claims are any bits of data that you want someone else to be able to read and/or verify but not alter.

Note: If that sounds buzz-wordy, don’t worry, it will all become clear in the next 5 mins of reading!


JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). ~ IETF

In English

To identify/authenticate people in your (web/mobile) app, put a standards-based token in the header or url of the page (or API endpoint) which proves the user has logged in and is allowed to access the desired content.


Note: if this does not look “secure” to you, scroll down to the “security” section.

What does a JWT Look Like?

Tokens are a string of “url safe” characters which encode information. Tokens have three components (separated by periods) (shown here on multiple lines for readability but used as a single string of text)

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9           // header
.eyJrZXkiOiJ2YWwiLCJpYXQiOjE0MjI2MDU0NDV9      // payload
.eUiabuiKv-8PYk2AkGY4Fb5KMZeorYBLw261JPQD5lM   // signature

1. Header

The first part of a JWT is an encoded string representation of a simple JavaScript object which describes the token along with the hashing algorithm used.

2. Payload

The second part of the JWT forms the core of the token. Payload length is proportional to the amount of data you store in the JWT. General rule of thumb is: store the bare minimum in the JWT.

3. Signature

The third, and final, part of the JWT is a signature generated based on the header (part one) and the body (part two) and will be used to verify that the JWT is valid.

What are “Claims”?

Claims are the predefined keys and their values:

  • iss: issuer of the token
  • exp: the expiration timestamp (reject tokens which have expired). Note: as defined in the spec, this must be in seconds.
  • iat: The time the JWT was issued. Can be used to determine the age of the JWT
  • nbf: “not before” is a future time when the token will become active.
  • jti: unique identifier for the JWT. Used to prevent the JWT from being re-used or replayed.
  • sub: subject of the token (rarely used)
  • aud: audience of the token (also rarely used)


Example contributions welcome

Lets get stuck in with a simple example. (the full source is in the /example directory)

TRY it:

To play around with the example you can open it in Gitpod (requires OAuth with GitHub).

Open in Gitpod


Using the core node.js http server we create 4 endpoints in /example/server.js:

  1. /home : home page (not essential but its where our login form is.)
  2. /auth : authenticate the visitor (returns error + login form if failed)
  3. /private : our restricted content - login required (valid session token) to see this page
  4. /logout : invalidates the token and logs out the user (prevent from re-using old token)

We have deliberately made server.js as simple as possible for:

  • Readability
  • Maintainability
  • Testability (all helper/handler methods are tested separately)

note: if you can make it simpler, please submit an issue to discuss!

Helper Methods

All the helper methods are kept in /example/lib/helpers.js The two most interesting/relevant methods are (simplified versions shown here):

// generate the JWT
function generateToken(req){
  return jwt.sign({
    auth:  'magic',
    agent: req.headers['user-agent'],
    exp:   Math.floor(new Date().getTime()/1000) + 7*24*60*60; // Note: in seconds!
  }, secret);  // secret is defined in the environment variable JWT_SECRET

Which generates our JWT token when the user authenticates (this is then sent back to the client in the Authorization header for use in subsequent requests),


// validate the token supplied in request header
function validate(req, res) {
  var token = req.headers.authorization;
  try {
    var decoded = jwt.verify(token, secret);
  } catch (e) {
    return authFail(res);
  if(!decoded || decoded.auth !== 'magic') {
    return authFail(res);
  } else {
    return privado(res, token);

Which checks the JWT supplied by the client is valid, shows private (“privado”) content to the requestor if valid and renders the authFail error page if its not.

Note: Yes, both these methods are synchronous. But, given that neither of these methods require any I/O or Network requests, its pretty safe to compute them synchronously.

Tip: If you’re looking for a Full Featured JWT Auth Hapi.js plugin (which does the verification/validation asynchronously) for your Hapi.js-based app please check out:


You may have noticed the [![Build Status][travis-image]][travis-url] badge at the start of this tutorial. This is a sign the author(s) are not just cobbling code together. The tests for both the server routes and helper functions are in: /example/test

  1. /example/test/functional.js - exercises all the helper methods we created in /example/lib/helpers.js Test Coverage
  2. /example/test/integration.js - simulates the requests a user would send to the server and tests the responses.

Please read through the tests and tell us if anything is unclear! Note: We wrote a basic “mock” of the http req/res objects see: /example/test/mock.js Confused/curious about Mocking? Read When to Mock (by “Uncle Bob”)

Frequently Asked Questions (FAQ)

Got a Question? Ask! »

Q: If I put the JWT in the URL or Header is it secure?

Good question! The quick answer is: No. Unless you are using SSL/TLS (https in your url) to encrypt the connection, sending the Token in-the-clear is always going to be insecure (the token can be intercepted and re-used by a bad person…). A naivemitigation” is to add verifiable “claims” to the token such as checking that the request came from the same browser (user-agent), IP address or more advanced “browser fingerprints” …

The solution is to either:

  • use one-time-use (single use) tokens (which expire after the link has been clicked) or
  • Don’t use url-tokens where high degree of security is required. (e.g: don’t send someone a link which allows them to perform a transaction)

Use-cases for a JWT token in a url are:

  • account verification - when you email a person a link after they register on your site.
  • password re-set - ensures that the person re-setting the password has access to the email belonging to the account.

Both of these are good candidates for single-use tokens (which expire after they have been clicked).

Q: How do we Invalidate sessions?

The person using your app has their device (phone/tablet/laptop) stolen. How do you invalidate the token they were using?

The idea behind JWT is that the tokens are stateless they can be computed by any node in a cluster and verified without a (slow) request to a database.

Store the Token in a Database?


If your app is small or you don’t want to have to run a Redis server, you can get most of the benefits of Redis by using LevelDB:

We can either store the valid Tokens in the DB or we can store the invalid tokens. Both of these require a round-trip to the DB to check if valid/invalid. So we prefer to store all tokens and update the valid property of the token from true to false.

Example record stored in LevelDB

"GUID" : {
  "auth" : "true",
  "created" : "timestamp",
  "uid" : "1234"

We would lookup this record by its GUID:

var db = require('level');
db.get(GUID, function(err, record){
  // pseudo-code
    // display private content
  } else {
    // show error message

see: example/lib/helpers.js validate method for detail.


Redis is the scalable way of storing your tokens.

If you are totally new to Redis read:

Redis Scales (provided you have the RAM):

Get Started with Redis today!


Quick answer: use Redis:

Q: Returning Visitor (no State Preservation between sessions)

Cookies are stored on the client and are sent by the browser to the server on every request. If the person closes their browser, cookies are preserved, so they can continue where they left off without having to log-in again. However, cookies will be sent on all requests that match the path and issuing domain, including those for images and css, where it isn’t needed.

localStorage provides a better mechanism for storing tokens during and between browser sessions.

Browser-based Applications

There are two options for storing your JWTs:

  1. Use localStorage to store your JWTs on the client side (means you need to remember to send the JWT in your authorization header for subsequent http/ajax requests)
  2. Store your JWT in a cookie (set and forget)

We obviously prefer the cookie-less approach. But if done right, cookies still have their place in modern web apps! (see the Auth0 article on “10 things you should know” in the further reading below)

Programmatic (API) Access

Other services accessing your API will have to store the token in a retrieval system (e.g: Redis or SQLite for mobile apps) and send the token back on each request.

How to generate secret key?

Apologies if this is mentioned elsewhere. The private key used for signing the tokens, is this the same as a private key generated using ssh-keygen?” ~ Originally asked by @skota see: dwyl/hapi-auth-jwt2/issues/48

Since JSON Web Tokens (JWT) do not have to be signed using asymmetric encryption you do not have to generate your secret key using ssh-keygen. You can just as easily use a strong password e.g: provided it’s long and random. The chance of collision (and thus someone being able to modify the payload, adding or modifying claims, and create a valid signature) is pretty low. And if you join two of those Strong Passwords (strings) together, you’ll have a 128bit ASCII String. So the chances of collision are less than the number of atoms in the universe.

To quickly and easily create a secret key using Node’s crypto library, run this command.

node -e "console.log(require('crypto').randomBytes(32).toString('hex'));"

In other words, you can use an RSA key, but you don’t have to.

The main thing you need to remember is: don’t share the key with people who are not in your core ("DevOps Team") or accidentally publish it by committing it to GitHub!

Which Node.js Module?

A search for “JSON Web Token” on NPM: yields many results!

npm search for json web token

Building a Web App with Hapi.js?

In our efforts to simplify using JWTs in Hapi.js apps, we wrote this module:

General Use in Other Node.js Projects

We highly recommend using the jsonwebtoken module made by our friends @auth0 (the identity/authentication experts):

Another great option is: by our friend @joaquimserafim

Essential Reading (Background)

Thanks for Learning with Us!

If you found this quick guide useful, please star it on GitHub! and re-tweet to share it with others:

olizilla tweet

comments powered by Disqus