Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Web Tokens

jwt.io

Post reply on HN
Print view View original

41–50 of 76 posts

Re: JSON Web Tokens

#41

Post by jfroma »

necubi wrote: post #2

JWTs are a pretty great solution for various authentication and authorization related problems, like OAuth tokens, password reset tokens and the like. Using an information-bearing (and signed) token like a JWT tends to make your web apps less stateful and simpler, by offloading the problems of determining authorizations to a single, central location. The main downside is that the representation (base64-encoded json)…

Yes, this is a real problem, tokens can get very large if you put too much information.

HTTP does not define any limit for headers, but most of the Web Servers have a default limit, Apache 8kb, IIS 16kb, nginx 4kb (see this question on SO [1]). If your JWT exceeds these limits you will get a "413 Entity Too Large".

It gets only worse if you need to use a query string instead of a header because the limits are lower and IE has a limit too [2].

Solution: carefully design your JWT, what information you will put on there. You usually don't need everything, store only the things you will use on every request, like the user id, name, email, roles are good candidates. Do not try to put the entire Facebook or Linkedin profile on a JWT.

Beside the limits, it will make the request bigger to transport and maybe even slower to verify.

[1]: http://stackoverflow.com/questions/686217/maximum-on-http-he... [2]: http://stackoverflow.com/questions/417142/what-is-the-maximu...

Re: JSON Web Tokens

#42

Post by jfroma »

hornetblack wrote: post #26
jsankey wrote: post #11

Just a heads-up: the font-weight of your lead paragraph makes it too light on Chrome+Windows, some of the diagonals pretty much disappear.

Same with Firefox on Linux. The 'S' letters are very noticeable.

Thanks for reporting this! I just open an issue here:

https://github.com/jsonwebtoken/jsonwebtoken.github.io/issue...

Re: JSON Web Tokens

#43

Post by jfroma »

akbar501 wrote: post #22
emeraldd wrote: post #5

How does this not lead to a situation where you are trusting the client for authentication/authorization information?

The client must send authentication credentials to the server. For example, a username/password that's provided by a user. There's nothing initially stored on the client that allows it to authenticate without user input. Of course, you could use a holder of token scheme to authenticate in the case of server to server communication. However, in this case you're making an assumption that both servers can prevent access…

You got that right.

In addition to what you described, the JWT spec also supports an RS family of algorithms (asymmetric). It means that you can sign with a private key and verify with a public key.

For instance Google, sign every JWT with the same private secret and publish their key for verification [1]. If you use this, your server-side application not only needs to verify that the JWT signature is correct but also that the audience is your application.

I wrote an example middleware for connect to verify Google's JWTs [2].

[1]: https://developers.google.com/accounts/docs/OAuth2Login#vali...

[2]: https://www.npmjs.org/package/connect-google-jwt

Re: JSON Web Tokens

#44

Post by haakon »

BrandonM wrote: post #39
haakon wrote: post #37

Earlier quoted context omitted.

This seems like a case where Base-85 [1] would have been a better choice than Base64. [1] http://rfc.zeromq.org/spec:32

Why would you consider Z85 to be a better choice? When you take URI encoding into account, Base64 is both simpler (no need for %-encoding)[0] and more space efficient (1.75 URI characters per byte for Z85, and 1.33 for Base64)[1]. The very first line on jwt.io says, JSON Web Token (JWT) is a compact URL-safe means of... ; being URI-safe appears to be an explicit design decision. [0] All but six of Z85's special chara…

Thanks, that's a nicely explained correction.

Re: JSON Web Tokens

#45

Post by flaie »

robotrobot wrote: post #34
alexanderblom wrote: post #21

Earlier quoted context omitted.

One way of doing it is having an out-of-bands way of refreshing tokens in responses. So if the token is about to expire you can return an updated one on the side-channel.

We've been doing this for a while in our angular apps using response interceptors: http://engineering.talis.com/articles/elegant-api-auth-angul...

This is a great write-up.

Re: JSON Web Tokens

#47

Post by julie1 »

just for the record there are some serious critics of oauth http://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-h...

I find jwt a tinge too complex. On the other hand no solution for unified AAA exists on web that makes sense: HTTP is a stateless protocol.

I sometimes wish people wake up from the Oauth insanity and realize using a statefull TCP connection would drop the sessions problem.

Why use stateful protocol (Oauth) for a stateless protocol (HTTP) over a statefull protocol (TCP)?

Emitting token lasting more than 1 hour impersonating the user in an hostile environment seems quite a lot of risk (mathematically speaking)

I must be a grumpy old dev, but I kind of hear the oauth sweet song of easy secure cross security token like sirens trying to seduce me for crashing my ship on the havoc of security.

Security is a mine field. One step out of the «right way» and boom, it does not work while burning 25% of your CPU power, an hidden tax.

Oauth protocol is a multi-dimensionnal maze designed under LSD at my opinion, and I kind of feel it unsafe to take.

Re: JSON Web Tokens

#48

Post by woloski »

gingerlime wrote: post #31

Sorry if this is a dumb question, but what's exactly the difference between JWT and OAuth? (EDIT: typo)

To start with, OAuth is an authoriation protocol and JWT is a token format (a signed and/or encrypted piece of data). So they are orthogonal.

The OAuth protocol doesn't specify which token format to use. Normally people have been using an "opaque" token, this is a token that doesn't have any meaning nor content but the meaning is stored somewhere. Here is an example of a table storing tokens and the scopes (permissions) associated to them. Every time an API Call is made, you would have to check against this table to see if the token sent in the Authorization header has the necessary scopes to call the API.

token | scopes oiajoeihfe9jh9283n | read.userinfo, post.friends uhuernvmiwmwo38h2g | read.userinfo

If you would use JWT you wouldn't have to store that information because it would be part of the token (i.e. stateless)

This would be a counterpart JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxMjM0NTY3O DkwLCJhdWQiOiJodHRwOi8vbXlhcGkiLCJzY29wZXMiOlsicmVhZC51c2VyaW5 mbyIsInBvc3QuZnJpZW5kcyJdfQ.tnLKyCWhVfkj2v15maCBJBVgPO08zFp2Lh n4Vkb4OoU

header: { "alg": "HS256", "typ": "JWT" }

payload: { "user_id": 1234567890, "aud": "http://myapi", "scopes": ["read.userinfo", "post.friends"] }

Google now changed their Authentication protocol to use OpenID Connect [1], which is a layer on top of OAuth plus a JSON Web Token. The thing about OpenID Connect which makes it useful for Authentication is that you can verify that the token (JWT) has been issued for your application (and not be used by another application) which was something the OAuth was lacking and a common vulnerability [2].

[1] https://developers.google.com/accounts/docs/OAuth2Login [2] http://homakov.blogspot.com.ar/2012/08/oauth2-one-accesstoke...

Re: JSON Web Tokens

#49

Post by glynjackson »

jperras wrote: post #46

For the Python users out there, the wonderful itsdangerous ( http://pythonhosted.org/itsdangerous/ ) library offers the ability to generate JSON Web Signature compliant tokens.

I have used itsdangerous a lot with DRF and it works really well, good call.

Re: JSON Web Tokens

#50

Post by protonfish »

Is the advantage of using this instead of basic auth and HTTPS that you don't have to use basic auth and HTTPS? (Or if not basic auth, an authenticated session cookie over HTTPS.) I've seen many people write their own system to avoid implementing HTTPS. Which, as much as installing certs is expensive and complicated (especially keeping track of expiration) should probably be done for all web sites for other privacy and security reasons.

Or is this for use in URL-passed data (like email links?) If so, is this better than including a token as a key to a one-time, limited-time activity stored on the server?

Post reply on HN