Sam4-square

I'm an Identity nerd with many years of experience as a developer and advocate. I love explaining complex topics clearly and understandably. You can find me on stage at developer events worldwide or simply having great conversations in the hallway. Google has recognized me as a Google Developer Expert (GDE) in the domains of Web Technologies, Security, Privacy, Payments, and Identity.

Principal Developer Advocate

Sam Bellen

To help you understand the WebAuthn configuration objects we've added a debugger to the webauthn.me website.



## Introducing the WebAuthn Debugger

**TL;DR** We've written about one of the latest additions to the [W3C specs](https://www.w3.org/TR/webauthn/), the [web authentication API](https://auth0.com/blog/introduction-to-web-authentication/), before. The API requires many configuration objects that you may be seeing for the first time. To help you understand these configuration variables we've added a [debugger to the webauthn.me website](https://webauthn.me/debugger). It lets you play around with different configurations and test them on the fly.

The Web Authentication API has 2 methods. A `create()` method to register new credentials and a `get()` method to use previously created credentials.

## Creating Credentials

Let's start with looking at the configuration for the `create()` method. Below you'll find some example code on how to use the `navigator.credentials.create()` method with some configuration in place. Let's break it down.

```
navigator.credentials.create({
 publicKey: {
   challenge: Uint8Array([1, 2, ... 3, 4]),
   rp: {
     id: 'webauthn.me',
     name: 'WebAuthn debugger'
   },
   user: {
     id: Uint8Array([1, 2, ... 3, 4]),
     name: 'Sam Bellen',
     displayName: 'Sambego'
   },
   pubKeyCredParams: [
     {
       type: "public-key",
       alg: -7
     }
   ],
   timeout: 15000,
   excludeCredentials: [{
       type: 'public-key',
       id: Uint8Array([4, 3, ... 2, 1]),
       transports: ['USB', 'NFC', 'BLE', 'internal']
   }],
   authenticatorSelection: {
       authenticatorAttachment: 'platform',
       requireResidentKey: true,
       userVerification: 'preferred'
   },
   attestation: 'direct',
 },
})
.then(console.log)
.catch(console.error);
```

### Challenge

The challenge is a buffer of randomly generated bytes with a minimum of 16 bytes. This is generated on the server using a [cryptographically secure random number generator](https://nodejs.org/api/crypto.html#crypto_crypto_randombytes_size_callback). By generating the challenge on the server we can prevent "replay attacks". The authenticator will sign this along with other data.

### Relying Party

This is the entity which is responsible for handling all things authentication, usually your authorization server or identity provider (IdP). The id must be the current domain or a subset of it. The name is used to describe the relying party.

### User

The user object contains profile information about the user like its name and preferred display name. It also contains a user id which is again a buffer with byte values. To ensure secure operation, authentication and authorization decisions must be made based on this user id, not the name or display name. The user id can not contain information that can identify a user, like a username or an email.

### Public Key Credential Parameters

This is a collection of accepted public key types. The algorithm (alg) is a number that references a key type in[ this list of COSE algorithms.](https://www.iana.org/assignments/cose/cose.xhtml#algorithms)

### Timeout

Defines the maximum time in milliseconds the user has to complete the registration action. This can be touching their authenticator device, TouchID or any other method used to interact with an authenticator.

### Excluded Credentials

You can use this if you wish to limit the creation of multiple credentials for the same account on a single authenticator. Your browser will throw an error if you try to create a new credential while one of the public keys in this collection already exists on the authenticator.

### Authenticator Selection

You can limit the type of authenticator devices you allow to register new credentials with part of the configuration. 

#### Authenticator Attachment

Only allow platform authenticators like TouchID or Windows Hello. You can also do the opposite, and only allow cross-platform authenticators like a Yubikey or a Google Titan Security Key. 

#### Require Resident Key

When set to true, the private key is stored on the authenticator. This means that the user can login without entering a username. This can be done with the `user.id` property we’ve seen before. The relying party will create a user handle which is stored in the resident key on the authenticator when creating a new credential. When authenticating the authenticator will return the user handle, so the relying party can look up the user linked to this user handle.

#### User Verification

Use the user verification option to only allow or discourage authenticators that verify the user is performing the registration. By checking a fingerprint with TouchID or doing facial recognition with Windows Hello the authenticator can verify the user performing the registration.

### Attestation

An attestation object is returned when completing the registration. With this parameter, you can specify if you want the attestation data from the authenticator as is (direct), or you're fine with anonymized (indirect) data.

When you successfully register a new credential, the `create()` method will return a credential object. This contains the id of the newly created credential in base64 and binary (rawID). We'll use this ID when authenticating a registered user with the second method specified by WebAuthn, `navigator.credentials.get()`

## Authenticating a User with a Previously Registered Credential

So you've registered a new credential, and now you want to authenticate using that credential. Like the `create()` method, the `get()` method also accepts a configuration object. Let's have a look.

```
navigator.credentials.get({
 publicKey: {
   challenge: Uint8Array([1, 2, ... 3, 4]),
   timeout: 15000,
   rpId: 'webauthn.me',
   allowCredentials: [{
       type: 'public-key',
       id: Uint8Array([1, 2, ... 3, 4]),
       transports: ['USB', 'NFC', 'BLE']
   }],
   userVerification: 'preferred'
 }
})
.then(console.log)
.catch(console.error);
```

### Challenge

Just as when registering a new credential, this is a buffer with cryptographically random bytes with a minimum length of 16 bits. Make sure you generate this challenge in a trusted environment, like a server.

### Timeout

Again, the optional timeout sets the time the user has to complete the authentication action.

### Relying Party Id

Also optional, you can specify the relying party. By default, the browser will use the current domain.

### Allowed Credentials

This is a collection of credentials the server would like the user to use for authentication. The credentials are listed in descending order, meaning that the relying party prefers the first, then second, and so on. We will pass the id we got back when completing the registration here.

## Wrapping up

WebAuthn is a new approach for a key-based registration and authentication on the web. By going through the most commonly used parts of the config you should be able to set up your WebAuthn process just right.

If you're still not sure which setting is best for you, [visit the online interactive WebAuthn debugger,](https://webauthn.me/debugger) and see how changing some options can change the registration and authentication process and result. The debugger has an easy to use interface which let’s you change the configuration objects and test them. It’ll display the results after you’ve finished the WebAuthn request. 

Do you still have some WebAuthn questions after reading this blog post, leave a comment below!


Enhancing webauthn.me with the Online Debugger Tool

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



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

bc94ff6211e645a2bdb4fdc60e23ad85

Former Auth0 Employee

Kassandra Perch

We've created a video showing of some of the cool features of our JWT Debugger for you to see


<include src="Vidyard" id="d8j9Txpk2R5pPLhbtGFFau" />

## Transcript

Hi, this is Kassandra with Auth0, and today we're gonna talk about the new JWT plugin that we've launched. So I've already installed it, and you can see the logo over here, and so I'm gonna click on it. And you can see the debugger. Now, there are quite a few features that are brand-new to this debugger that I want to show you. One of the first ones is this "Open JWT From." So what I'm gonna do is, it says, "Web Storage" and "Cookies," so I'm actually going to use the local storage API to save a JWT into local storage and show you how you can debug it.

Okay, now to do that, what I'm going to do is say, "localStorage.setItem()" with our token. Okay. So now I'm going to reopen the JWT debugger and go to Open JWT From. And as you can see, my token now shows up here. Now it does still say invalid signature, so I'm gonna have to change the secret to the secret I made this key with, and you can now see signature verified, just like with the JWT debugger on the webpage. You can also share JWTs with this button. You copy the URL, and it will send people to the debugger on the website.

One of the other really cool things you can do with the JWT plugin is decode and check RSA signed JWTs. And so I've pasted one in here, and as you can see, it wants my public and private key. I'm gonna put in my public key here, and I'm gonna take my private key off there. And I'm gonna put that here. And as you can see, the signature is now verified. This can come in handy in many, many situations. So basically if you're working on a site using JWTs, you can now pull those JWTs from local storage or cookies, and no matter what you used to encode them, be it a public, private key pair or an HS256 secret, you can debug them in your browser without even having to leave.

Hopefully this will inspire you to [download the debugger yourself](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd?hl=en). I'm Kassandra Perch with Auth0. Thanks for watching.


Learn more about the new JWT Debugger Chrome Extension

Do you like JWT.io? Then you'll love this extension!



Do you find yourself visiting [JWT.io](https://jwt.io) a lot to debug your tokens? Then you'll love what we have in store for you: [JWT.io as a Chrome extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) with extra features!

<include src="TweetQuote" quoteText="Debug JWTs from your browser with our new extension: https://goo.gl/axNsXn"/>

-----

## A New Chrome Extension
We noticed many users rely on [JWT.io](https://jwt.io) to debug their JWTs. And with good reason! The colored visual editor is intuitive and has support for both HMAC and RSA signed JWTs. So we thought: what if we made this available offline for all users with a few extra features? So our [new Chrome extension](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) was born.

## Features
- Visual JWT editor with coloring:
![JWT Debugger](https://images.ctfassets.net/23aumh6u8s0i/6kNIm4984TkoHc56HSWpw4/12e31ed46fb4001384321f0624273634/editor)

- Support for HS256 (HMAC + SHA256) signed JWTs:
![JWT Debugger HS256 support](https://images.ctfassets.net/23aumh6u8s0i/7HtwQ0sZRJpQzXI8GNIC77/be00c8f35eedbe242c7849cba440e5d2/hs256-2)

- Support for RS256 (RSA) signed JWTs:
![JWT Debugger RS256 support](https://images.ctfassets.net/23aumh6u8s0i/BHrWz3ctLpLumgRPozIUM/7cac276fedfd8956e02c49fc465c16ea/rs256-2)

- Load and save JWTs in cookies and web storage from the current tab:
![JWT Debugger load from cookies/web storage](https://images.ctfassets.net/23aumh6u8s0i/33ZIvbcX2GIIGo3aZbzkaC/c0ae9508862cd211898db57eb8023d0a/load-from)

- Get a shareable URL for your JWTs:
![JWT Debugger shareable URL](https://images.ctfassets.net/23aumh6u8s0i/4Gp39AxqZH41lM9XxOzkjU/af9f4bb9d589ff2100ad78a5f477421e/share-2)

[Try it out now](https://chrome.google.com/webstore/detail/jwt-debugger/ppmmlchacdbknfphdeafcbmklcghghmd) and give us your feedback! Can you think of any other features you'd love to have? Tell us below in the comments or through Chrome's Web Store.

<include src="asides/Jwt" />


"debugger"