jsonwebtoken / jsonwebtoken.github.io Goto Github PK

It would be great if the definitions of the built-in claims of the spec (e.g. jti, iat, etc.) could be seen by hovering over the claim name. As a first step, it might be useful to highlight these claims in some way as to distinguish them from custom claims.

For a list of claims, see https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-32#section-4.1.

Howdy all,

sorry if I overlooked it but I cannot seem to find any docs on the steps to getting a new library added to the website.

I see a few other issues where people are asking to be added so I may not be the only one.

Thanks!

Make it easier to share a URL to jwt.io that contains a web token. A couple ideas:

• Automatically update the URL with the ?value=token whenever the token is modified in the editor/viewer.
• Display a shareable URL somewhere on the page that I can copy/paste.

A default message that reads: unable to validate signature - please provide a key would be a better choice than displaying this:

I ran the payload from an Auth0 article in the debugger and it fails with message "Invalid Signature."

Payload:

{
  iat: 1416929061,
  jti: "802057ff9b5b4eb7fbb8856b6eb2cc5b",
  scopes: {
    users: {
      actions: ['read', 'create']
    },
    users_app_metadata: {
      actions: ['read', 'create']
    }
  }
}

Shouldn't it require tokens to be base64url encoded (by the book)?

Expected Flow

1. User should be able to pick/select from a list of supported signature types, as a dropdown or tabs at the debugger: http://jwt.io/#debugger

   

   Note: UI/UX implementation may vary, the main concern is the implementation.

2. Depending on the algorithm selected for the signature, the user should dispose of an input[type="text"] or an input[type="file"] at the signature edit section.

   

   Note: Secret keys should never be uploaded.

Cant scroll maybe?

Are there any other alternatives like utf8?

subject, #151

There are a few issues I found:

When clicking on the textbox and holding the delete key only one character is deleted and the delete key is released. The expected iOS behavior is that you can click and hold to continually delete.
You cannot click and hold to select the text thus making it difficult to clear the textbook.
You cannot click and hold to copy or paste. Paste is most problematic because it makes the site impossible to use on iOS unless you memorize and type the key manually.
Here is a video of the interactions. At then end you will see me trying to click, click and hold, etc.

https://www.dropbox.com/s/26bw8lkp380k8lv/2015-02-06_12-24-24.mp4?dl=0

My guess is we are just intercepting too many events incorrectly. One nice thing would be on mobile browsers that once you click on the text box it automatically clears then the user can easily paste in the box.

Hello,

We developed a new gem for ruby, we support exp, iss and aud.

Not sure what's the approach you're taking on the web, but you could show both ruby implementations.

Hi,

I created a new PHP library.
Even if this library has to be improved, it is quite stable now.

This is a very complete library and provides:

• JWK support
• JWKSet support,
• JWS support including:
  • all signature algorithms support
  • Compact, Flattened or multiple signature serialisation representation support,
• JWE support including
  • all key encryption algorithms support
  • all content encryption algorithms support
  • compression support
  • Compact, Flattened or multiple recipients serialisation representation support,

More information at Spomky-Labs/jose.
The documentation is not complete.

It will be great if you can test it and send me feedbacks.

Could you add mention about D implementation http://code.dlang.org/packages/jwtd

Reported here:

https://news.ycombinator.com/item?id=8283415

Your list of libraries is missing the second most popular jwt ruby gem:

https://github.com/nov/json-jwt

https://rubygems.org/search?utf8=%E2%9C%93&query=jwt

In security related areas we should always show good practices in examples:

As the secret in the HS256 example a secret based on the recommendations from RFC 4868 should be used: The length of the secret should at least the size of the block size of the hash function (64 bytes for SHA256). The used "secret" is way to short.

I know this isn't the easiest fix given this is hosted on GitHub, but a site where people paste in potentially-secret tokens should not be served over HTTP. Granted, someone concerned about security should not be pasting into a web form in the first place... but let's be real, it happens. Thoughts?

Refs isaacs/github#156

This implementation for JWT https://bitbucket.org/connect2id/nimbus-jose-jwt/wiki/Home
seems to be more feature complete than the current suggestion and maybe should be the actual suggestion for java developers. We use it productively for JWT creation and checking.

Would you accept a PR allowing all default state values to be passed in via the URL hash?

This would be win for projects that want to refer to jwt.io in their documentation/examples. See, for example, how we point to jwt.io from the example at the bottom of http://docs.smarthealthit.org/authorization/backend-services/ -- it would be nice to provide a complete working link instead of asking the user to paste in sample values for claims, public key, and private key.

For a site with a similar mechanism, see this feel link to the json-ld playground

As we can see here firebase/php-jwt library doesn't support some algorithms described on https://jwt.io home page.
It supports only HS256, HS512, HS384, RS256

Would be nice to show the human readable iat and exp fields.

Maybe even highlight if the token has already expired?

While adding a new library I had to deal with explicitly setting specific icons. It'd be nice if I could just edit a JSON/YAML/TOML/INI file and not be concerned with the layout.

Hey guys, unsure if you list only high level JWT implementation on your site or just JOSE will work, but here is couple libraries with full alg suite.

https://github.com/dvsekhvalnov/jose2go
https://github.com/dvsekhvalnov/jose-jwt
https://github.com/dvsekhvalnov/jose-rt (not full yet)

See #6 and #8.

• Header mobile
• Favicons
• cancel animation when debugging
• Text effect header
• Focus jump
• Fix heroku's issues https://jwt-io.herokuapp.com/
• Alert message
• Mainteiner & Stars count https://cloudup.com/c8d6NbCPKX3
• Add title Store https://cloudup.com/cHn5EzKPiOP
• On click select all the text https://cloudup.com/cn84u0wdHMD
• Update logos jwt
• Add banner auth0 the same call to action CREATE FREE ACCOUNT
• Float right https://cloudup.com/cXOi2VfiHEc

My user model consists of : email,username,password,gravatar(all are of type String)
sample input:
email:[email protected]
username:abc
password:****
gravatar://www.gravatar.com/avatar/900150983cd24fb0d6963f7d28e17f72?s=40&d=retro

Unable to encode above gravatar value into jsonwebtoken

I've looked at multiple libraries that all claimed to support ECDSA signing but didn't implement the RFC correctly.

I think you should require libraries to include some proof that they implemented the RFCs correctly before being accepted in the JWT library list.

For example they could link to some tests/code example which uses the test vectors mentioned in RFC 7520.

Most of the libraries I've seen only test their verification implementation against their own signing implementation. This is a bad practice. They should at least test against the RFC 7520 examples to prove they've implemented signing and verification correctly.

Although the algorithms are described elsewhere, it would be nice to have a little guide to choosing an algorithm for your JWTs on this page.

Hi there,

I just spotted that the number of stars of each library is outdated. For instance, spomky-labs/jose displays 15 stars on jwt.io, in fact it has more than 50 stars.

Is there something we can do for that?
Thank you

The links in the Lua (openresty) section point to the Scala library:

The JWT Swift library provided by Auth0 is not shown in the list of libraries.

Hi there,

I have recently prepared the jwt implementation for the Haxe language. It would be my pleasure to get it listed on the website. The repo can be found here.

Supported features at the moment:
Sign, verify, iss check, aud check, exp check, HS256

Thanks,
Kevin

Hi guys,

just as an idea may be it's time to start tracking not only signing, but also encryption and JWK support?

Many libraries looks absolutely same in your list (e.g. almost all support full suite for signing). But if you dig to extended capabilities it will make difference.

Probably it even make sense to split support to: JWT (iss, nbf and other semantic claims), JOSE (sig and encryption) and JWK.

The info box regarding json_web_token for ruby is indicating the library supports verifying claims, but it is not verifying claims (even says so in the readme).

Hey y'all, I'm working on a pure SQL postgresql implementation of JWT:

https://github.com/michelp/pgjwt

Right now I have sign, verify, and HS256/384/512. Are you interested in me sending a PR to add the implementation to your page?

Thanks,

-Michel

Came back to my chugging machine, and turns out Firefox is using 7GB of memory -- had to force quit, but restored the session so I could repeat the process, and running about:memory on the same sites turns out that http://jwt.io has some sort of leak. Here's an image of the memory usage after a few hours of jwt.io being open, using over a gig of memory.

https://github.com/square/js-jose

Hi! I'm happy to take this, but which branch should I be working from? Looks like chrome-extension, but that's diverged a bit from master and currently has merge conflicts.

Suggestions?

Noticed that by passing ?value=<JWT> you can populate the debugger. Might be a good idea to have some kind of share button around so you can share the URL for the current value in the debugger.

I'm noticing that some libraries (ruby JWT) are stripping padding '=' and making a base64 string that is not decodable without re-appending '=' (which is what the ruby JWT does)

Of course I'm generating the JWT and using /verifying it in another language.

Does JWT officially have a position on the base64 standard and padding?

Would it be possible to make "conforms to standard base64 " part of the checkboxes that you have in the list of libraries.

Best Regards,

Curtis

Please also support HMAC512 signing.

Hi there,

The only reasonable implementation of JWT I've seen in Scala is: https://github.com/jasongoodwin/authentikat-jwt

I'd be happy to do the PR to change the HTML, but I have no idea what spec it verifies against, etc.

Do you guys want to check it out and make it passes the spec?

I have so much CPU and RAM I can't even recall numbers, I know I can open as much as 4 resource-hog IDE's written in Java and feel no slightest glimpse of slowdown.

Then I open jwt.io, all GUI feels sluggish, and whatever browser I use to open, takes near all CPU as of htop.

Where's no version info in index.html, wget jwt.io -O - | md5sum = 54929852d61a4736925d199cb72e2bcc.

Please fix, or do release comprehensive command line utilty to manipulate tokens.

P.S. OS is Ubuntu updated daily, browsers are latest Firefox and Chrome.

This has got to be one of the weirdest issues I have encountered. Tokens with two undescores in encoded base64 format do not work on the jwt.io site.

Add the following message as token in the jwt.io site: {"?":"aa?"}

The resulting token is: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyI_IjoiYWE_In0.y88bwJcmo-S3xoYBPEARz3oJkeDaHN9TbvAiOABYoxQ

Now try pasteing the same token back in to jwt.io. The result is that the JSON box in the middle stays empty.

Now change one of the _ characters to any base64url character, for example -. The token magically appears and now shows: { "?": "aa>" }

Most likely this is UTF-8 encoded. It's rendered correctly elsewhere :)

Related to #22

url: https://github.com/SkyLothar/lua-resty-jwt
check support:
- nbf
- exp
alg:

• HS256
• HS512

I believe #16 blocks this, but here's another lib option for PHP: https://github.com/lcobucci/jwt