001c9ddc5ceb9829b6aaf24f5d28502a

I am software developer with a keen interest in open-source technologies, Linux, and native development. I've worked on many different platforms Android, iOS, Win32, Linux, FreeRTOS, the Web, and others. I've gone through the whole stack and I enjoy learning and using the latest technologies. I now work as a full-stack developer at Auth0.

Senior Engineer

Sebastian Peyrott

We have released new versions of JWT.io and the JWT Debugger extension, learn what's new.



We have released another round of updates for our [JWT.io](https://jwt.io/) website and the JWT Debugger extensions ([Chrome](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)). Among the new features are [HMAC](https://en.wikipedia.org/wiki/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.

<include src="TweetQuote" quoteText="A new round of updates for JWT.io and the JWT Debugger extensions have been released!"/>

---

## JWT.io and the JWT Debugger extension
[JSON Web Tokens (JWTs)](https://jwt.io/introduction/) 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](https://jwt.io/) provides a convenient way to debug and inspect [JSON Web Tokens (JWTs)](https://auth0.com/e-books/jwt-handbook), 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](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd), [Firefox](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)) are the [Web Extension](https://browserext.github.io/browserext/) 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](https://auth0.com/blog/brute-forcing-hs256-is-possible-the-importance-of-using-strong-keys-to-sign-jwts/), 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](https://images.ctfassets.net/23aumh6u8s0i/7bsOiqkha9rbIRXBIaeVhm/ffafe28856d614488a591a39dcdf4cbc/1-hmac-hint-1)

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

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/2-hmac-hint-2.mp4" controls autoplay loop></video>

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.

### Share Button
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!

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/3-share-button.mp4" controls autoplay loop></video>

### Easy Library Updates
Since its inception, adding a new library to the library list at JWT.io has been a cumbersome process. Several [Pug](https://pugjs.org/) 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:

```json
{
  "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](https://github.com/jsonwebtoken/jsonwebtoken.github.io/blob/master/README.md) 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!

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/4-jwt-io-callback.mp4" controls autoplay loop></video>

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

<a href="https://auth0.com/signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">Sign up for a free Auth0 account</a> 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.

<video src="https://cdn.auth0.com/blog/jwt-io-updates-2/5-claims-tooltips.mp4" controls autoplay loop></video>

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](https://stackoverflow.com/questions/18039401/how-can-i-transform-between-the-two-styles-of-public-key-format-one-begin-rsa) 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!

<include src="TweetQuote" quoteText="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!"/>

## 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](https://github.com/jsonwebtoken/jsonwebtoken.github.io/blob/master/README.md).
- Implemented some **design changes**.
- Passed the **100 combined tests** mark!
- And fixed a good deal of bugs.

<include src="asides/Jwt" />

## 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](https://github.com/jsonwebtoken/jsonwebtoken.github.io/issues).

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](https://tools.ietf.org/html/rfc8037).
- 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](https://github.com/jsonwebtoken/jsonwebtoken.github.io/issues). Hack on!


Another Round of JWT.io and JWT Debugger Extension Updates

Learn the best practices for keeping your JWTs secure.

A Look at The Draft for JWT Best Current Practices



We have released a major update to our [JWT.io](https://jwt.io/) website and the [JWT Debugger](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) extension based on it. Among the new features, there are new signing algorithms, improved public-key handling, human-readable timestamps, and even [Firefox support](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger) for the extension! In this post, we will go over these new features.

<include src="TweetQuote" quoteText="JWT.io and the JWT Debugger extension have been updated with new features!"/>

---

## JWT.io and the JWT Debugger extension
[JSON Web Tokens (JWTs)](https://jwt.io/introduction/) 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](https://jwt.io/) provides a convenient way to debug and inspect [JSON Web Tokens (JWTs)](https://auth0.com/e-books/jwt-handbook), 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 extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) is the [Web Extension](https://browserext.github.io/browserext/) version 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!

New versions of JWT.io and the JWT Debugger extension have been released. Let's go over the changes.

## New Features
### New Signing Algorithms
For a long time, JWT.io and the JWT Debugger extension only supported the two most popular algorithms: HS256 and RS256. HS256 is an HMAC-based algorithm that relies on a shared secret between parties to produce and verify signatures. On the other hand, RS256 is an RSA-based algorithm, relying on public and private key pairs to sign and verify signatures. The advantages of RS256 are clear: signatures can only be produced by the private-key holder, while verification can be performed by anyone holding the public key. However, the complexity of the implementation for RS256 can make HS256 signatures better for certain use cases (embedded, small devices, etc.).

![New algorithms](https://images.ctfassets.net/23aumh6u8s0i/1NaGCSea11eRFPXlrqP2EO/daed2abf80e328068b91d25647d6f087/1-new-algs)

The new version of JWT.io and the extensions support many more algorithms:

#### HMAC
- HS384
- HS512

These are variants of HS256. HMAC signatures rely on a hash function to produce and verify the signature. In the case of HS256, the hash function is SHA-256. For the other two, the hash functions are SHA-384 and SHA-512. For certain use cases, SHA-512 exhibits better performance than the other two. Security wise, none of these hash functions has been broken.

#### RSA
- RS384
- RS512
- PS256
- PS384

Much like the HMAC counterparts, RSA signatures also rely on a hash function to produce and verify a signature. The same thing changes between RS256, RS384, and RS512.

PS256/384 use a different type of signature (RSA-PSS) that also relies on the RSA algorithm as the baseline. In particular, it uses an encoding method that relies on a random salt value. This produces probabilistic rather than deterministic signatures. It is considered stronger than RS256/384/512 signatures as long as the random salt is truly random. In case the salt is not truly random, it provides the same level of strength as the baseline RSA algorithm

#### ECDSA
- ES256
- ES384

These algorithms rely on the elliptic-curve digital signing algorithm (ECDSA) rather than RSA. The main advantage of ECDSA is that keys can be smaller for a similar level of cryptographic strength. A 256-bit ECDSA key provides a cryptographic strength similar to a 3248-bit RSA key. This makes ECDSA keys better for certain hardware limited devices.

> If you are interested in a detailed rundown of JWT signing algorithms, don't forget to check our [JWT Handbook](https://auth0.com/e-books/jwt-handbook). Chapter 7 goes over all signing algorithms in detail.

#### "none"
JWTs also support setting the `alg` claim to `none`. This means that the JWT is not signed. Unfortunately, this has resulted in [critical vulnerabilities in JSON Web Token libraries](https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/). For this reason, JWT.io and the JWT Debugger extensions now consider `alg: "none"` tokens always _invalid_.

### Automatic Public-Key Download
Another interesting feature that has been added is automatic public key downloads. Public-key algorithms, such as RSA, RSA-PSS, and ECDSA, rely on public-keys to verify signatures. Public-keys, like their name implies, can be safely shared without compromising the security of the signature. For this reason, it is not uncommon for JWT public-keys to be available either embedded in the token itself, or in a public URL.

JWT.io and the JWT Debugger extensions now attempt to get public keys in different ways according to the claims embedded in the token.

If the token contains both the `iss` and `kid` claims, JWT.io will attempt to download the token from a specially crafted URL. For example:

```javascript
header: {
  kid: 1
},
payload: {
  iss: "https://username.auth0.com/"
}
```

In this case, JWT.io and the extensions will attempt to download the key with `kid = 1` from the special URL `https://username.auth0.com/.well-known/jwks.json`. This is a [common scheme used by Auth0](https://auth0.com/docs/jwks). In other words, all Auth0 JWTs can now be verified in JWT.io and the JWT Debugger extension by simply pasting the token!

<include src="TweetQuote" quoteText="With automatic key downloads, all Auth0 JWTs can now be verified in JWT.io and the JWT Debugger extension by simply pasting the token!"/>

Of course, since the JWK and JWS standards declare other common schemes for specifying keys, these are also supported: the `jwk`, `jku`, `x5c`, and `x5u` claims. These are used to either embed a key within the token (`jwk` and `x5c`) or to declare a URL to get the keys or certificates (`jku` and `x5u`). For example:

```javascript
header: {
  kid: 1,
  jku: "https://username.auth0.com/.well-known/jwks.json"
}
```

In this case, JWT.io and the extensions will attempt to download the key with `kid = 1` from the URL `https://username.auth0.com/.well-known/jwks.json` specified in the `jku` claim.

### Human Readable Timestamps
Several JWT claims are time-based. For instance, the `iat` claim specifies the exact time the JWT was issued at, the `exp` claim specifies the expiration time for the JWT, the `nbf` sets the time when the JWT becomes valid, etc. Unfortunately, these claims are based on the [Unix epoch](https://en.wikipedia.org/wiki/Unix_time): they specify the number of seconds elapsed since January 1st, 1970. Understanding these values by simply looking at them is hard. For this reason, now JWT.io and the JWT Debugger extensions display a tooltip when the mouse hovers over a supported time claim.

![Human readable timestamps](https://images.ctfassets.net/23aumh6u8s0i/KAGGuSxmdUdMO3YeLBJfh/a21a8482154c72bf97bb527ed7b670b0/2-timestamps)

The supported claims are: `exp`, `iat`, `nbf`, `auth_time`, and `updated_at`.

### Firefox Support
Yes! It's finally here. Ever since the first release of the JWT Debugger extension for Chrome we have received requests for a Firefox version. Now it's here and supports all the features of the Chrome extension. [Get it here](https://addons.mozilla.org/en-US/firefox/addon/jwtio-debugger)!

![JWT Debugger on Firefox](https://images.ctfassets.net/23aumh6u8s0i/3oxA0AoIwuIHbRGmi2gcqh/eb843e039c0aa895d02963ecd0eabb51/3-firefox)

## Streamlined Codebase
Although the new features are the cool part of the release, we have also done a ton of internal work on both JWT.io and the extensions. In particular:

- We have closed over 40 issues and merged over 15 pull requests (some with more libraries!).
- We have synchronized the codebases of JWT.io and the JWT Debugger extensions to always get the latest features out to you, regardless of what you use more.
- We have updated all internal dependencies to the latest versions. This has fixed many bugs here and there and also improved the experience on mobile platforms.
- We have performed a major refactor to improve code quality and latencies during page load. JWT.io is now faster than ever!
- We have added more tests to our test suite. Do check that these pass before submitting new PRs!
- Build scripts are now simpler. Want to contribute? Doing so is as simple as:

Steps:

1. [Checkout from Git](https://github.com/jsonwebtoken/jsonwebtoken.github.io/).
2. `npm install`
3. `grunt`

That's it! You will now find JWT.io available on [http://localhost:8000](http://localhost:8000) and ready for your changes. The extension is also built but you'll need to load it manually in your browser, see the Chrome or Firefox docs for help with this. The resulting code can always be found in the `dist` folder. Send your PRs!

<include src="asides/Jwt" />

## What's Next
Although we have just finished with these changes, there's still more in our pipeline!

- **Key-length tips:** we will show you tooltips when your shared secrets are not long enough.
- **Share button:** the extensions already support this, now it's coming to JWT.io!
- **Library submission process:** we get tons of PRs with new libraries, we want to formalize the process and setup tools so that you can easily review any steps that are required to add your library to JWT.io

We hope you enjoy all the new features and changes at [JWT.io](https://jwt.io/) and the JWT Debugger extensions. Please report any bugs at the [GitHub repository](https://github.com/jsonwebtoken/jsonwebtoken.github.io/) and don't forget to leave us your comments or requests here or in the issue tracker at GitHub. Cheers!



JWT.io and JWT Debugger Extension Updates

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g avatar

685342d5e7f42c3ab8d251d7d4a53308?s=100&d=mm&r=g

Former Auth0 Employee

Robin Percy

Continuing on from my Introduction to Crystal article, this time we're going to build our first Crystal web app and authenticate users via JSON Web Tokens.

"json-web-tokens"