JWT (JSON Web Token) debugger
jwt.io
jwt.io
Then this one liner in the browser console can be used for most purposes:
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); })();
# 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' <<<"
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.
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!
https://addons.mozilla.org/en-US/firefox/addon/duckduckgo-fo...
> 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.
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.
JWTs are very hard to use correctly. That's the entire problem. Don't use them. Use PASETO.
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.
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.
(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)
I think it might take quite a few changes though. Very interesting idea.
It's considered insecure to store them in local storage for XSS etc
Where / how are you storing them locally for headless apps?
https://news.ycombinator.com/item?id=21783303 6 month ago 227 comments (first comment by dang referencing all the other posts)
https://news.ycombinator.com/item?id=22354534 3 months ago 166 comments
and a bunch of other discussions: https://hn.algolia.com/?q=jwt
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.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.