How to Use JSON Web Tokens • Hacker News Board

Re: How to Use JSON Web Tokens

#51

Post by schnable » Wed, Jan 02, 2019, 5:41 PM UTC

Dowwie wrote: post #2

JWTs are radioactive. Proceed with caution.

This meme is getting out of hand. Yes, JWTs may be inappropriate compared to putting a session id in a cookie, but there are many uses for JWTs outside of web app session handling. There are a couple serious implementation pitfalls to be aware of, but the bottom line is that JWT is a convenient and standardized way to construct a secure bearer token.

Despite the pitfalls, most folks that need a bearer token format (not just a web session) are probably better off using JWTs than rolling their owns solution.

Re: How to Use JSON Web Tokens

#52

Post by hinkley » Wed, Jan 02, 2019, 5:42 PM UTC

KaiserPro wrote: post #17

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 aren’t required to be competent to put out a spec. Just join a committee.

Did you ever look at the XML digital signature spec? You could drive a freight train through the holes in that one. One guy did an entire conference presentation on the ones he found (took me about a year to find nearly all of the same ones and a few more).

Re: How to Use JSON Web Tokens

#53

Post by pkulak » Wed, Jan 02, 2019, 5:42 PM UTC

manigandham wrote: post #32

KaiserPro wrote: post #17

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…

To be clear, cookies are an HTTP header field that can carry any text data you want. You can pass plain text, JWTs or any other encrypted payload (which many web frameworks do automatically). JWTs aren't comparable to cookies, they're just a standard way to sign data.

His or her point was that if you don't sign and/or encrypt, there's no benefit over a standard cookie.

Re: How to Use JSON Web Tokens

#54

Post by [deleted] » Wed, Jan 02, 2019, 5:46 PM UTC

EGreg wrote: post #44

I used to just follow whatever people said in oAuth and oAuth 2. No longer. Once I started questioning why we need all these tokens, when we will anyway have to look up access information in some database, I got pretty much no satisfying answers: https://security.stackexchange.com/questions/161734/why-does... The token may as well just be an AUTENTICATION token, such as the app’s id with timestamp signed with the sha…

[deleted]

Re: How to Use JSON Web Tokens

#55

Post by smadge » Wed, Jan 02, 2019, 5:47 PM UTC

mattferderer wrote: post #39

KaiserPro wrote: post #17

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…

> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conf…

> Sharing data between servers & clients while being able to make sure the data wasn't changed.

I think the main use is sharing data between the server and itself. The client shouldn’t depend on the internal structure of the token. The token should just be issued by the server to the client, and the client passes it along to subsequent requests to the server.

Re: How to Use JSON Web Tokens

#56

Post by hinkley » Wed, Jan 02, 2019, 5:47 PM UTC

incadenza wrote: post #50

redbeard0x0a wrote: post #28

Earlier quoted context omitted.

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.

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

When are you expiring tokens ahead of their natural expiration date? When someone logs out?

Isn’t that state? If you add state to something stateless you are generally on your own.

[edit: also I disagree with the notion that something with an expiration date is stateless. It has two states. It’s just that the look like idenpotence]

Re: How to Use JSON Web Tokens

#57

Post by lambdadmitry » Wed, Jan 02, 2019, 5:53 PM UTC

KaiserPro wrote: post #17

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…

> unless you encrypt your token after you generate it

Generally it's better to avoid unauthenticated encryption. That is, encrypt-than-sign, not the other way around.

Re: How to Use JSON Web Tokens

#58

Post by dec0dedab0de » Wed, Jan 02, 2019, 5:56 PM UTC

sjroot wrote: 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.

I recently started using JWT and had the same problem, I ended up keep the expiration very low and having the client constantly refresh when they need it, and just forget it when they don't

Re: How to Use JSON Web Tokens

#59

Post by evan_ » Wed, Jan 02, 2019, 6:07 PM UTC

incadenza wrote: post #50

redbeard0x0a wrote: post #28

Earlier quoted context omitted.

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.

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

One way to look at it is, presumably you will have far fewer revocations than active sessions, so why optimize for that case?

Instead of an "active sessions" table you could just maintain a list of revoked sessions and check each incoming request against that list. You can make revocations expire shortly after the JWT was set to expire.

Re: How to Use JSON Web Tokens

#60

Post by incadenza » Wed, Jan 02, 2019, 6:07 PM UTC

hinkley wrote: post #56

incadenza wrote: post #50

Earlier quoted context omitted.

My issue here is that expiring JWTs involve adding state! The whole point of JWTs is stateless authentication, so I’ve never understood the advantage over sessions unless revoking tokens is never an option.

When are you expiring tokens ahead of their natural expiration date? When someone logs out? Isn’t that state? If you add state to something stateless you are generally on your own. [edit: also I disagree with the notion that something with an expiration date is stateless. It has two states. It’s just that the look like idenpotence]

Perhaps revoking is the better term here. At least that's the use case I had in mind. If you want the ability to revoke a token, you have to have some list of black listed tokens somewhere.