Live data from Hacker News

How to Use JSON Web Tokens

github.com

21–30 of 135 posts

Re: How to Use JSON Web Tokens

#21
post #3
post #2

JWTs are radioactive. Proceed with caution.

I keep hearing this. Is there a good writeup available?

Most of the "discussion" on this topic spins out of this blog post: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba.... Which unfortunately is:

1. A bit unnecessarily abrasive and hysterical in its style, and

2. Comes from a PHP consulting firm, promoting their own alternative proposal (which hardly anyone else seems to discuss or use). So I think #1 above is really about drawing eyeballs and selling services, more so than providing clear information for a newcomer to follow.

JWT does have its issues, though. They basically break down into two points:

1. Because of its distributed nature, there's no built-in way to invalidate a JWT prior to its natural expiration. You have to roll your own approach for this, typically some sort of whitelist or blacklist mechanism (which defeats some of JWT's advantages).

2. By default, the spec and its major library implementations allow JWT's to specify a number of different signing algorithms (including "None"!). This is dangerously nonobvious for newbies. Best practice is to configure your code to only allow a limited number of algorithms (i.e. one).

Re: How to Use JSON Web Tokens

#23

Earlier quoted context omitted.

> JWTs can be read by every script you add to your site, making XSS attacks easier. A cookie with the HttpOnly flag prevents this. You're confusing JWTs (a standardized token / means of representing claims) and JavaScript localStorage (a storage which can be read by scripts, partitioned by origin). The two are completely orthogonal; you could store a JWT in a cookie, if you wanted to. > JWTs [… make] XSS attacks easi…

> you could store a JWT in a cookie, if you wanted to. Huh? If it's an HTTPOnly cookie, how would you then insert the JWT token into the auth header?

If you’re using a cookie to store the JWT, you don’t really need to check the auth header.

Re: How to Use JSON Web Tokens

#24
post #4
post #3

Earlier quoted context omitted.

I keep hearing this. Is there a good writeup available?

The parent comment isn't very helpful, but from what I understand people dislike JWTs because it makes it hard to invalidate a session without some sort of work-around. For example, you can use 2 tokens, one short lived, and one long lived to get around the invalidation problem, but then you will need to occasionally validate that both tokens are still valid, and that state needs to be stored, and now you're storing…

Isn't that basically oauth?

Re: How to Use JSON Web Tokens

#25

This is a good Javascript-centric writeup. This caught my eye thought: > Since JSON Web Tokens (JWT) are not signed using asymmetric encryption ... You don't have to, but can of course sign your JWTs with asymmetric keys, and many libraries support this. Third party token issuers (firebase, google, auth0) require asymmetric, since they're clearly not going to share a secret with you. Asymmetric also provides two-way…

I've dealt with and used JWTs in a few different applications, and all of them have used assymetric keys, and used as tokens passed between different systems. Keeping the private key only on the issuing system is more secure (or even essential, depending on what you're doing).

If you're authenticating on the same system, you could get away with symmetric, but then the use of JWTs may no longer make sense vs just using a random key stored persistently on the server (eg, for session cookie, "remember me" or "forgot password" token) -- I actually can't think of a case where using JWTs makes sense if you have access to persistent storage. By storing the random value you can also revoke it server side, which you can't do normally do with JWTs.

Re: How to Use JSON Web Tokens

#26

JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…

You can have unsigned, signed, or encrypted JWTs. You're correct that many JWT libraries only do signed tokens by default, but there's a whole spec devoted to encryption: https://tools.ietf.org/html/rfc7516 (whether or not your library of choice implements it is a separate question)

Re: How to Use JSON Web Tokens

#28
post #20

This page doesn’t have any discussion of strategies for expiring JWT, one of the biggest security issues with this auth mechanism. Even the code sample doesn’t include an expiration.

The JWT has a built-in field called exp, which is the time the token is expired. This is built in.

However if you need to 'expire' a JWT token early, there isn't a good way to do it. If your token has a JTI, then you could add a blacklist for that JTI (say in redis, with a TTL until the token's exp time). But that is left to the implementor.

Re: How to Use JSON Web Tokens

#29
post #24
post #4

Earlier quoted context omitted.

The parent comment isn't very helpful, but from what I understand people dislike JWTs because it makes it hard to invalidate a session without some sort of work-around. For example, you can use 2 tokens, one short lived, and one long lived to get around the invalidation problem, but then you will need to occasionally validate that both tokens are still valid, and that state needs to be stored, and now you're storing…

Isn't that basically oauth?

Yes. In a web setting (the most common use case for JWT), they are typically issued during an oauth dance.

Re: How to Use JSON Web Tokens

#30

JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…

As mentioned in the article you might want the token to be read by the users. Such as issuing a token with a expiry date that you want the user to regenerate. Although If anything the JWT libraries should have encryption enabled by default.
Post reply on HN