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

How to Use JSON Web Tokens

github.com

Post reply on HN
Print view View original

71–80 of 135 posts

Re: How to Use JSON Web Tokens

#71

Post by shkkmo »

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

The page mentions the ‘exp’ field, but doesn’t use it in its example. I was suggesting the author point out the fact that, if someone gets a hold of a JWT without an expiration, then your system is in quite a bit of trouble.

It is up to your implementation if you consider JWTs without an exp field to be valid.

Our implementation requires a number of fields that are optional in the spec.

Re: How to Use JSON Web Tokens

#73

Post by geezerjay »

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.

> My issue here is that expiring JWTs involve adding state!

I don't agree. The expiration timestamp is not a state, nor is a nonce/token id. Moreover the specs enable servers to arbitrarily reject tokens, which means servers can arbitrarily request token refreshes. This means that any argument regarding how a nonce is a state is entirely irrelevant and without any practical interest.

Re: How to Use JSON Web Tokens

#74

Post by geezerjay »

iamwil wrote: post #68
hinkley wrote: post #56

Earlier quoted context omitted.

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]

When someone's account is compromised, is another situation.

> When someone's account is compromised, is another situation.

Why is that scenario relevant if tokens are supposed to be used once per request and short-lived?

Once a token is used, it's supposed to be expired and no longer in use. Both the expiry timestamp and the nonce fields already handle those use cases.

Re: How to Use JSON Web Tokens

#75

Post by TekMol »

At first JWTs look cool because you can log in users without managing session data on the server.

Then you think about how a user can actively log out.

Then you add session management to your server but call it 'token invalidation'.

Re: How to Use JSON Web Tokens

#76

Post by andrewstuart2 »

TekMol wrote: post #75

At first JWTs look cool because you can log in users without managing session data on the server. Then you think about how a user can actively log out. Then you add session management to your server but call it 'token invalidation'.

This is a problem you have with any federated token-based identity solution. Distributed logout is a hard problem which can basically be reduced to cache invalidation (insert N/N-1 hard things in CS joke here).

Re: How to Use JSON Web Tokens

#77

Post by nwhatt »

andrewstuart2 wrote: post #31
ForHackernews wrote: post #26

Earlier quoted context omitted.

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)

This is one of the things I truly appreciate about JWT. They made it a) easy and b) possible to do signing, encryption, or both. If you've ever taken a shot at learning the specs behind SAML, the simplicity of JWT is hugely refreshing.

Thank you for comparing it to SAML. I feel like anytime JWT is mentioned on HN people jump to discard it as rubbish, but really it's useful for people who actually need to exchange claims.

Re: How to Use JSON Web Tokens

#78

Post by kbenson »

techslave wrote: post #69
pkulak wrote: post #53

Earlier quoted context omitted.

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

not sure if that was the point or not, but it's wrong. even if you did sign/encrypt, that's not a benefit over a standard cookie. you can easily sign or encrypt a 'standard cookie' as well. the benefit is the portability that comes from a standardized and widely used data structure.

You say that as if cookies haven't been a standardized and widely used data structure (key-value store) for decades.

Re: How to Use JSON Web Tokens

#79

Post by andrewstuart2 »

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.

Invalidation of any sort, including token revocation, is fundamentally a stateful operation. Either you are deleting session state or statefully blacklisting something that's a packet of self-contained state (e.g. JWT by id). Heck, even expiration just reduces the revocation into the universally shared state that is time.

My point is, you always have state. If you care about that state being anything but _the current time_ (e.g. just letting tokens expire and not worrying about revocation), you need shared storage.

Re: How to Use JSON Web Tokens

#80

Post by andrewstuart2 »

dec0dedab0de wrote: post #58
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

This is a very popular conclusion when considering AuthN and invalidation. Keep the state at the provider and just prevent issuance of new tokens (whether signed certs, JWTs, etc) if/when the user requests access be revoked.

What you're really doing is externalizing your state to one already universally shared, and which we already have a lot of tools to manage: the current time.

Post reply on HN