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

JWT is Awesome

thehftguy.com

Post reply on HN
Print view View original

161–170 of 170 posts

Re: JWT is Awesome

#161

Post by toyg »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

Authentication and authorization are different things, if the latter is done properly a bit of waiting for the former is no biggie.

Re: JWT is Awesome

#162

Post by jmkni »

sk5t wrote: post #74
jmkni wrote: post #34

Earlier quoted context omitted.

Noob question, what is pinning in the context of JWT?

Your question is a good one, and "pinning" is not a very appropriate term here. Whitelist acceptable algorithms by issuer, ok fine--you have to have a library of acceptable public keys or shared secrets to go along with each of the allowed algorithms anyway. The JWT consuming infrastructure here on top of jose4j uses a registry of keyinfo metadata to allow for provision of multiple expirable keys and supported algori…

Thanks!

Re: JWT is Awesome

#163

Post by schnable »

jteppinette wrote: post #137
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

Stakeholder: “so you are saying that after a user is denied access they can still access the resources?” Dev: “yes, but only for 15 minutes. Also, it makes our system more simple and decreases database calls, increase performance, ...” Stakeholder: “nope”

This tradeoff comes up all the time on highly scaled systems, and stakeholders rarely if ever say "nope" in my experience.

Re: JWT is Awesome

#164

Post by rp2684 »

logicalmind wrote: post #149
tracker1 wrote: post #97

Earlier quoted context omitted.

Don't blacklist, use shorter lived tokens and have the client refresh as needed. A 10-15m token is plenty long life and not so long as it's a huge risk window, more than even a shorter window,.

But isn't the requirement for using the refresh token that it must be kept secure? For example, if you users authenticate in a browser, they get back an access token and a refresh token. If that refresh token were stolen on the wire or from within the browser, how would you prevent someone from using that refresh token perpetually if you're not blacklisting?

In this case, you would have to use rotating refresh tokens (https://tools.ietf.org/html/rfc6819#section-5.2.2.3). They are essentially one-time use refresh tokens and help in token theft detection. So essentially, both, the access and the refresh token keep changing. You can learn more about implementation details and its benefits here: https://supertokens.io/blog/the-best-way-to-securely-manage-...

Re: JWT is Awesome

#165

Post by cryptica »

Supermancho wrote: post #111
enumjorge wrote: post #71

Earlier quoted context omitted.

Can you elaborate why session IDs inside cookies is dangerous?

I can manipulate my cookies. I can forge my servserside session id for session hijacking. This is what I understood.

I didn't think so detailed but yes. My point was more that if you look at any technology concept, you will find vulnerabilities if it is misused.

Re: JWT is Awesome

#166

Post by logicalmind »

rp2684 wrote: post #164
logicalmind wrote: post #149

Earlier quoted context omitted.

But isn't the requirement for using the refresh token that it must be kept secure? For example, if you users authenticate in a browser, they get back an access token and a refresh token. If that refresh token were stolen on the wire or from within the browser, how would you prevent someone from using that refresh token perpetually if you're not blacklisting?

In this case, you would have to use rotating refresh tokens ( https://tools.ietf.org/html/rfc6819#section-5.2.2.3 ). They are essentially one-time use refresh tokens and help in token theft detection. So essentially, both, the access and the refresh token keep changing. You can learn more about implementation details and its benefits here: https://supertokens.io/blog/the-best-way-to-securely-manage-...

This is essentially an inverse blacklist (aka refresh token whitelist) which requires server-side state. The part that these things seem to miss in my mind, especially in situations where security requirements are high, is that the authentication process is equivalent to the refresh process.

For example, you can have a complicated authentication process where you require a password, 2FA, etc. These things help ensure that the user is that user. But once that process completes, it is replaced with access_token+refresh_token. Any user can take those item and impersonate that user. Attempts to lock this down require server-side state with the ability to revoke stolen tokens if detected.

Don't get me wrong, the same issues arise if you were using cookie-based session id's or the equivalent. But once you're doing this stateful token stuff, there appears to be a lot of additional complexity without a lot of additional benefit over the traditional way.

However, if you aren't worried about this level of security, there is clearly a benefit to using this newer style.

Re: JWT is Awesome

#167

Post by user5994461 »

gorgonian wrote: post #155
spookthesunset wrote: post #139

Earlier quoted context omitted.

For parts of the site where you need to boot somebody instantly... just hit up the authentication server on every request to validate the session. For parts of the site where it doesn’t matter so much, wait for the token to expire.... It isn’t all or nothing.

I did exactly this on the last implementation of JWT I did. Common actions wouldn’t hit the database if the token was less than an hour old, but actions like changing email address or password would always check the database.

This just made me realize. There is an even simpler way to achieve the same result without a database.

The token includes the time when it was created (iat attribute) so critical actions could check that the token is less than 3 minutes old.

Re: JWT is Awesome

#168

Post by gorgonian »

user5994461 wrote: post #167
gorgonian wrote: post #155

Earlier quoted context omitted.

I did exactly this on the last implementation of JWT I did. Common actions wouldn’t hit the database if the token was less than an hour old, but actions like changing email address or password would always check the database.

This just made me realize. There is an even simpler way to achieve the same result without a database. The token includes the time when it was created (iat attribute) so critical actions could check that the token is less than 3 minutes old.

Yeah that’s what I did, with iat info. But I did that for every request, and critical actions always hit the db.

Re: JWT is Awesome

#169

Post by nijave »

user5994461 wrote: post #148
peeters wrote: post #114

Earlier quoted context omitted.

Yeah I was hoping for a fair comparison but it seemed like a pretty big strawman. Like he just takes it for granted that "a session cookie is a cryptographically-signed identifier" but that's not remotely standard. At its most common (looking at you, JSESSIONID), simple form, the session cookie is a securely generated random number that is used as an index for state, and signing plays no part. The presenter then goes…

Author here. Random identifiers and encoded objects are both widely used historically. Random cookies might have been more common 2 decades ago when every byte was expensive, but that was a while ago. If you work mainly in Java for example, you'll more often see JSESSIONID which are random string identifiers, referring to a database containing active tokens and user profiles. However if you work in Python, you'll mor…

Sure Django and Flask use secure session cookies but that doesn't automatically make them all secure or signed/encrypted. Most cookies are plain text and there's no reason they need to be secure (they just contain user metadata not auth information)

Re: JWT is Awesome

#170

Post by tptacek »

Ficirdly wrote: post #57
teyc wrote: post #32

https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally…

Just not Macaroons again :( Macaroons have many small edge cases that'll bite you when you try to use them in practice: - there is no spec and all people re-implement the de-facto standard. If you read the whitepaper it's not what's in use. - the de-facto implementation is full of holes, e.g. time is expressed without timezone so it's not clear if it's UTC or not. - the implementation requires custom parser for custo…

I agree that people need to do more research than just reading a blog post.

But we are not on the same page about Macaroons and what makes them interesting. I do not care about interoperability and standardization (I do sometimes, but not here). Apart from things like OIDC, most of the JWT usage I see is internal to projects; they're used as a utility library to do utility crypto in HTTP APIs. In those scenarios, it doesn't matter whether "your" Macaroons are the same as mine.

What's interesting about Macaroons are the underlying design.

I'm honestly surprised to hear that anyone would go into a project with something like Macaroons and expect to fit into a pre-existing ecosystem of compatible Macaroon implementations, because, as the post says, they're not widely used.

Post reply on HN