42 comments

[ 1.7 ms ] story [ 91.5 ms ] thread
I'm always amazed on which content show up on the front page, there is currently a 15 minutes window on /newest and the most upvoted article is about a page which doesn't really bring anything new, humm
A neat thing about this is that it doesn't send your tokens over the wire which is good security-wise :)
With similar web apps (e.g. hashing of passwords) I was thinking it would be great to be able to show to the user that this web page can't send data anywhere once it is loaded

(I understand that this might be tricky or even impossible (?) to ensure in browsers but it would be interesting to be able to give and prove guarantees like that to the user)

In the developer console, I can disable the internet connection for a tab. I wonder if that could be leveraged somehow.

I think it might take quite a few changes though. Very interesting idea.

It's usually the first place I go to check base64 or other cryptic information
Bless this debugger, saved me so much time when implementing Sign in with Apple
Within my team I call this the best website in the world.
I'd like to mention here that PASETO is a safer JWT alternative:

https://github.com/paragonie/paseto

For the uninitiated:

> Unlike JSON Web Tokens (JWT), which gives developers more than enough rope with which to hang themselves, Paseto only allows secure operations. JWT gives you "algorithm agility", Paseto gives you "versioned protocols". It's incredibly unlikely that you'll be able to use Paseto in an insecure way.

Thank you, sorry, I probably should have included that.
I have yet to see a criticism of JWT that doesn't devolve into developers not understanding them and/or misusing them.

Like, I know some devs use them for stateless auth, which means you can't revoke a token, so a stolen token is guaranteed valid until expiration, but I'd file that under misuse.

Hmm, I'm not understanding your point. You say you haven't seen a criticism of JWT that's not just "they're very hard to use correctly", as if that invalidates that criticism.

JWTs are very hard to use correctly. That's the entire problem. Don't use them. Use PASETO.

More like...

They're easy to use correctly, but just as easy to use incorrectly.

But this applies to a lot of technologies. Some people treat Base64 like encryption. I've seen passwords stored in databases with Base64 encoding. It doesn't mean Base64 is terrible and insecure, it just means it's being used incorrectly.

I mean, if the official base64 website said "base64 is an open, industry standard method for storing passwords securely in databases", I'd agree with you, but it's only JWT.io that makes that claim.

If you're making a security library that's easy to use incorrectly, it's not easy to use correctly, and it's probably more of an insecurity library.

So which one is a JWT hackers?

  A) v1.local.CuizxAzVIz5bCqAjsZpXXV5mk_WWGHbVxmdF81DORwyYcMLvzoUHUmS_VKvJ1hn5zXyoMkygkEYLM2LM00uBI3G9gXC5VrZCUM-BLZo1q9IDIncAZTxYkE1NUTMz

  B) eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhpIEhhY2tlciBOZXdzIiwiaWF0IjoxNTE2MjM5MDIyfQ.IlIR9_imqGCgEVG_QUb4LhDwSeNhYc50t3Ij5x126scVNJFQqCveblmHx__tqjaI

  C) ATkJzynwvPlX6PxBU5BO5xa96S6vymIbmIZnk9og7KxhLHqYLoneLK6WTkyyuGFk7uWZZUnQFVTaThmHzFvaf

  D) gAAAAABezWTi-jcq7zlfBaR0vGUy-B9WJ_3lL6S48JO7t9LiW4283zOqBAJvJZEAvusn7OKpgyyoPp2p7okVE4TQfYuihDou67vOHH6G0zqdQz0_1NLvSTM=
If you know which one it is straightaway, then it is the worst choice out of all of them, (because it is not encrypted by default). I would chose the least obvious one here.
I'm not sure what you're trying to say here? Only one of these is a valid JWT.
You can recognize JWTs without decoding by checking the string format:

JSON Web Tokens follow this format → ALGO+TokenType.Payload.Signature

So obviously the only valid JWT in your question is “B”.

    B) eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9
       .
       eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6
       IkhpIEhhY2tlciBOZXdzIiwiaWF0IjoxNTE2
       MjM5MDIyfQ
       .
       IlIR9_imqGCgEVG_QUb4LhDwSeNhYc50t3Ij
       5x126scVNJFQqCveblmHx__tqjaI
But this does not matter because you are not supposed to decode random strings expecting them to be JSON Web Tokens. That would be as stupid as assuming that any 32-bytes string is MD5 or any 40-bytes string is SHA1, etc. You either know what your input’s format is or you do not in which case you should not even attempt to decode it because it clearly is not a valid input.
And another party trick: Base64-encoded JSON objects always start with "ey".
JWTs don't concern themselves with privacy, only authenticity. The fact you can read the JWT is irrelevant.
Looking into the page inspector shows 165 http requests on the start page. It includes ads, tracker and analystics from multiple sources (google, twitter, linkedin, facebook etc).

Can anyone sugguest an (offline?) alternative?

I used jwt.io a lot for debugging and it's great. Currently it is decoding the tokens on the client but I am not sure if I should continue using it.

A hacker could take over the site and capture thousands of access tokens and some are valid for multiple days.

Edit: Installing uBlock origin reduces the number of requests down to 67 but I still see the analytics stuff from google and twitter.

You can pretty easily parse + verify JWTs in Bash using cut + base64 + openssl, although the precise invocations depend on which "alg"s you're using.
The website source is here: https://github.com/jsonwebtoken/jsonwebtoken.github.io

I've been running a local copy since last year sometime, when the website went down when I needed it. I've also stripped away all the annoying things from the website to just get the debugger. Very easy to do!

Thanks. I once searched for it but only found some used libraries.
Yeah, Auth0 is doing a good job hiding it, seems they are not super hyped about the website being open source.
What makes you think that? There's a link in jwt.io's footer to the GitHub repo.
If you are not afraid of the command line, have a look at smallstep [1]. I use it all the time for JWT debugging, and it can do other things as well.

[1] https://github.com/smallstep/cli

JWT Debugger App is a good alternative. It’s cross-platform so you can install on you local desktop or just use web version whatever works for you.

https://jwtdebugger.app/

Good to know : You can only paste parts of the token and it will decode it without any problem. I always leave the signature part out of it when I use this tool.
Just curious, why do you leave the signature out?
If you have concerns that the page might steal the tokens, leaving out the signature if you're not trying to debug it prevents a valid token from touching the site.
If you want to avoid pasting tokens in online tools (right now it looks like they don't send out / record anything, but as a general practice, pasting sensitive tokens in online tools is probably not the best idea)

Then this one liner in the browser console can be used for most purposes:

  JSON.stringify(JSON.parse(atob(TOKENHERE.split('.')[1])), null, 2);
> JSON.stringify(JSON.parse(atob(TOKENHERE.split('.')[1])), null, 2);

Non-code version for mobile users.

My contribution: a bookmarklet I use to copy JWTs from my internal sites to the clipboard. Replace jwt_name with your name

javascript: (function() { var textArea = document.createElement("textarea"); textArea.value = window.sessionStorage.jwt_name; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); document.body.removeChild(textArea); })();

I found these aliases online and have found them quite useful. Requires jq.

# JWT Payload. Provide the JWT as the argument e.g. jwtp "$JWT"

alias jwtp="jq -R 'split(\".\") | .[1] | @base64d | fromjson' <<<"

# JWT Header. Provide the JWT as the argument e.g. jwth "$JWT"

alias jwth="jq -R 'split(\".\") | .[0] | @base64d | fromjson' <<<"

If you're using JWTs for authentication.

It's considered insecure to store them in local storage for XSS etc

Where / how are you storing them locally for headless apps?