Another Round of JWT.io and JWT Debugger Extension Updates

We have released another round of updates for our JWT.io website and the JWT Debugger extensions (Chrome, Firefox). Among the new features are HMAC secret length hints, common claim descriptions, simplified library updates for the website, a share button for the website, support for plain RSA public keys, and more token types can be passed in the URL! In this post, we will go over these new features.

"A new round of updates for JWT.io and the JWT Debugger extensions have been released!"
Tweet This

JWT.io and the JWT Debugger extension

JSON Web Tokens (JWTs) are a convenient way to exchange claims between parties. The key features of JWTs are their simple format (Base64-encoded JSON) and the use of signatures and/or encryption. JWT.io provides a convenient way to debug and inspect JSON Web Tokens (JWTs), along with an introduction to some of the key concepts behind them. It also provides a list of libraries and frameworks that can be used with them in many different programming languages.

The JWT Debugger extensions (Chrome, Firefox) are the Web Extension versions of JWT.io. The debugger has the same features as the website but can be used offline. It also provides additional features like automatic inspection of web storage and cookies to easily find and edit JWTs in websites!

Now, let's go over the new features of this release!

New Features

HMAC Secret Length Hints

As we have seen on our blog before, the length of the HMAC secret is one of the fundamental properties to ensure it cannot be brute forced. For this reason, we have added two hints:

The default secret for all HMAC token examples now hints at the minimum required length.

Default secret for HS256 example

When typing, a tooltip appears if the secret is too short to be considered safe.

Do note, however, that length is not the only thing that is important for secrets. They must also be hard to guess, or, in other words, completely random.

A share button to easily pass tokens in URL form has been requested many times, and indeed, it was already available in the extension. Now it is also available on the website!

Easy Library Updates

Since its inception, adding a new library to the library list at JWT.io has been a cumbersome process. Several Pug and CSS files needed to be edited. Furthermore, editing an existing library had its problems too: to change features one had to remember class names, for example. We have finally modernized the process. Now libraries are located in the views/website/libraries folder. There, you will find a JSON file for each language or framework. Inside the JSON file you'll see something like this:

{
  "name": "Node.js",
  "uniqueClass": "node",
  "image": "/img/2.svg",
  "bgColor": "rgb(138, 194, 68)",
  "libs": [
    {
      "minimumVersion": "4.2.2",
      "support": {
        "sign": true,
        "verify": true,
        "iss": false,
        "sub": false,
        "aud": true,
        "exp": true,
        "nbf": false,
        "iat": false,
        "jti": false,
        "hs256": true,
        "hs384": true,
        "hs512": true,
        "rs256": true,
        "rs384": true,
        "rs512": true,
        "es256": true,
        "es384": true,
        "es512": true
      },
      "authorUrl": "https://github.com/auth0",
      "authorName": "Auth0",
      "gitHubRepoPath": "auth0/node-jsonwebtoken",
      "repoUrl": "https://github.com/auth0/node-jsonwebtoken",
      "installCommandHtml": "npm install jsonwebtoken"
    }
  ]
}

Multiple libraries go in the libs array. Most of the JSON file is self-explanatory, but some values are optional. For full details, check out the README file.

To add a language or framework, a new JSON file must be created. The name of the file should start with a number, followed by a name, and end with .json. No further changes are required (other than editing the contents of the file).

It really is that simple!

JWT.io as OpenID Connect Callback

One of the uses that JWT.io originally supported, was to be set as the callback for OpenID Connect operations (you can do this from the Auth0 Dashboard). That way, after a successful login, developers could be sent automatically to JWT.io with the returned token in the editor. This was disabled a long time ago during refactors. But now, that feature is back!

The following URL parameters are recognized: access_token, id_token, token, and value.

to try this out!

Common Claims Tooltips

In our previous update, we had enabled tooltips for dates in claims. This time, we have extended tooltips to also show a short description of what the claim means.

Of course, human-readable dates still work.

Plain RSA Public Keys

Some RSA implementations work using the old PEM-encoded RSA public key without the X.509 SubjectPublicKeyInfo header that is much more common nowadays. Unfortunately, old versions of JWT.io did not support these keys. But that's no longer the case! Plain RSA keys of yore are now supported, try it out!

"The new round of features for JWT.io include: HMAC secret length hints, a share button, easy library updates, JWT.io as OIDC callback, common claim tooltips, and plain RSA pubkeys!"
Tweet This

Other Changes

Of course, not every change in this release is related to new features. In this release, we have also:

Merged all PRs.
Added 6 new libraries (thanks to external contributors!).
Updates 12 libraries (thanks again to external contributors!).
Improved the README file.
Implemented some design changes.
Passed the 100 combined tests mark!
And fixed a good deal of bugs.

Aside: Delegating JWT Implementation to the Experts

JWTs are an integral part of the OpenID Connect standard, an identity layer that sits on top of the OAuth2 framework. Auth0 is an OpenID Connect certified identity platform. This means that if you pick Auth0 you can be sure it is 100% interoperable with any third party system that also follows the specification.

The OpenID Connect specification requires the use of the JWT format for ID tokens, which contain user profile information (such as the user's name and email) represented in the form of claims. These claims are statements about the user, which can be trusted if the consumer of the token can verify its signature.

While the OAuth2 specification doesn't mandate a format for access tokens, used to grant applications access to APIs on behalf of users, the industry has widely embraced the use of JWTs for these as well.

As a developer, you shouldn't have to worry about directly validating, verifying, or decoding authentication-related JWTs in your services. You can use modern SDKs from Auth0 to handle the correct implementation and usage of JWTs, knowing that they follow the latest industry best practices and are regularly updated to address known security risks.

For example, the Auth0 SDK for Single Page Applications provides a method for extracting user information from an ID Token, auth0.getUser.

If you want to try out the Auth0 platform, sign up for a free account and get started! With your free account, you will have access to the following features:

To learn more about JWTs, their internal structure, the different types of algorithms that can be used with them, and other common uses for them, check out the JWT Handbook.

What's Next

After all these changes, we will now let the codebase stabilize for a while. Of course, if you find any bugs, please report them in the bug tracker.

But that is not all! We are also thinking of more ways of improving JWT.io. Here are some of the ideas we are considering at the moment:

Adding a button to clear the last saved token.
Allowing the selection of different tokens passed in as URL parameters (access_token vs id_token for example).
Support more algorithms, such as ES512 or the new EdDSA signatures.
Undock capability for the extensions (if possible).

What are your thoughts? Don't hesitate to tell us in the comments or by opening an enhancement request in the bug-tracker. Hack on!

Another Round of JWT.io and JWT Debugger Extension Updates

Tweet This

JWT.io and the JWT Debugger extension