How to Use JSON Web Tokens • Hacker News Board

Re: How to Use JSON Web Tokens

#111

Post by incadenza » Wed, Jan 02, 2019, 10:36 PM UTC

geezerjay wrote: post #109

incadenza wrote: post #94

Earlier quoted context omitted.

I'm failing to see how this is complicated. Imagine the following: 1) A token gets compromised. 2) You know which token. You need to revoke access. 3) You introduce state by storing said token on disk / in memory somewhere. Key takeaways: 1) The authentication system (not the token) is now stateful. 2) You now have to check this data store to properly allow authentication. 3) A core benefit of JWT (stateless auth) is…

> 1) A token gets compromised. Tokens are single-use and short-lived. Once a token is used it's revoked. > 2) You know which token. You need to revoke access. > 3) You introduce state by storing said token on disk / in memory somewhere. You don't. You simply reject the token and let the client refresh its token. That's it. There is no state. Compliant clients already expect tokens to be rejected for no apparent reaso…

There's so much conceptual / factual confusion in this post I just don't know where to start. Agree to disagree I guess.

Re: How to Use JSON Web Tokens

#112

Post by jillesvangurp » Wed, Jan 02, 2019, 10:52 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.

You can set a ttl in the JWT and you should. But I think you are talking about using jwts as session cookies, which is indeed not something you should be doing without having a reliable way to invalidate them if you care about reliable signout and token invalidation. For that ttls are not a great solution.

We don't currently use them for sessions, but I've been planning to. When we do, we'll have a mechanism for invalidating tokens, just like we currently do for our oauth tokens. One way would be to simply embed that in the jwt as a field and check that on each request, just like we do already with oauth. The biggest risk with either oauth or jwt tokens is somebody intercepting them and using them. This risk is about the same for both but it does need consideration.

We are using jwts internally for authorizing messages on our queues and internal API calls. Those jwts have very short ttls and don't leave our infrastructure. They typically include assertions on scope, userids, etc. I've been considering to make JWTs the native format on our queues; i.e. embed the message in the JWT rather than a jwt in the message. This would make message tampering harder for any man in the middle attacks. We already uses nonces in some of our messages so we'd be able to prevent replay attacks this way as well.

The main benefit of using jwts is that verifying them is trivial and can be done without network interaction. Very nice in a microservice type architecture. Jwts are issued on our API server are after verifying the oauth token (not jwt currently). We don't leak these tokens outside our infrastructure currently and we don't have public endpoints that would accept them in any case. None of this is new but not that common in modern REST/graphql type setups nevertheless. JWTs are probably easy enough to retrofit in most APIs that it might be worthwhile exploring this for many.

If you are interested, we open sourced our Java code for creating/verifying JWTs. Check here for an example and more code: https://github.com/Inbot/inbot-utils/blob/master/src/test/ja...

Re: How to Use JSON Web Tokens

#113

Post by paulddraper » Wed, Jan 02, 2019, 11:06 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…

> Why in this day an age is encryption not a default for the _payload_?

Why would it be? Why not encrypt the disk and use SSL?

Doing encryption right can be enormously difficult; why not use the transport/storage technologies that are ubiquitous?

Re: How to Use JSON Web Tokens

#114

Post by CiPHPerCoder » Wed, Jan 02, 2019, 11:35 PM UTC

kevinburke wrote: post #92

andrewstuart2 wrote: post #89

Earlier quoted context omitted.

I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid s…

Well the good news is I've written about this exact subject at length! I have seen JWT implementations at five or six different companies now, tokens have never been used for more than one use case. For each specific use case you'd actually want to use it with there is a better solution that doesn't involve JWT, like secretbox or HMAC-SHA256. https://kev.inburke.com/kevin/things-to-use-instead-of-jwt/

You might be happy to see the PASETO spec, which (for v2) uses XChaCha20-Poly1305 for encryption, Ed25519 for signatures, separates the two logically, and doesn't allow for runtime ciphersuite negotiation. (v1 achieves a similar result with AES-CTR+HMAC-SHA384-EtM and RSASSA-PSS.)

https://github.com/paragonie/paseto/tree/master/docs/01-Prot...

It's similar to the advice given above, but also caters to that itch that some project managers have to only implement industry standards (which PASETO is slowly becoming).

Re: How to Use JSON Web Tokens

#115

Post by Kalium » Wed, Jan 02, 2019, 11:48 PM UTC

paulddraper wrote: post #113

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…

> Why in this day an age is encryption not a default for the _payload_? Why would it be? Why not encrypt the disk and use SSL? Doing encryption right can be enormously difficult; why not use the transport/storage technologies that are ubiquitous?

You're right. Doing encryption correctly can be incredibly difficult and complex. Enough so that people might miss important subtleties of the technologies at hand.

For instance, you may want the encryption of data-in-transit to be removed by the application, rather than by whatever is responsible for TLS termination. You may not want your load balancer to be capable of reading the most sensitive data of your request.

Re: How to Use JSON Web Tokens

#116

Post by andrewstuart2 » Thu, Jan 03, 2019, 3:33 AM UTC

tptacek wrote: post #110

andrewstuart2 wrote: post #108

Earlier quoted context omitted.

To be honest, and with all due respect, avoiding JWT outright feels a lot like a cargo cult to me. I have yet to see a solid argument against JWT itself, aside from the criticisms you just gave of "it doesn't minimize the set of things that can go wrong." In reality, that statement is like saying "x509 doesn't minimize the set of things that can go wrong." The criticism is leveled at JWT as if the JWT spec attempts t…

I'm not sure how you can "cargo cult" not casually adopting some random piece of technology. The Pacific cargo cults transformed incidental interactions with modernity into religious venerations; aboriginal islanders got free supplies from visiting GIs, believed the experience to have been supernatural, and built wooden airplane replicas as idols in hopes of summoning those benefits anew. The comparison to JWT is pre…

I'm disappointed. From your reputation and from having heard you speak on podcasts, I expected a bit more enlightening and friendly conversation than condescension and subtle insults.

Regarding cargo cults around an opinion, consider this scenario:

1. Be a successful public figure in some domain.

2. Share opinion related to said domain.

3. People elevate opinion itself because of relation to successful individual without adequately examining and understanding the facts.

I'm not saying you're wrong, but I am saying I'm not satisfied with the arguments I've seen. The JWT spec (specifically, the RFC) simply leaves many decisions up to people building on top of it. Given its flexibility, I fail to see how any of your arguments preclude it from being used as part of a stricter standard that is more "misuse resistant."

Regarding blind buzzword acceptance, though, that's a human problem, not a technology problem. If something is useful, and intuitive enough that it gains popularity, I can guarantee that many people will find a way to misuse it while stamping the buzzword on their resume.

Re: How to Use JSON Web Tokens

#117

Post by tptacek » Thu, Jan 03, 2019, 3:34 AM UTC

andrewstuart2 wrote: post #116

tptacek wrote: post #110

Earlier quoted context omitted.

I'm not sure how you can "cargo cult" not casually adopting some random piece of technology. The Pacific cargo cults transformed incidental interactions with modernity into religious venerations; aboriginal islanders got free supplies from visiting GIs, believed the experience to have been supernatural, and built wooden airplane replicas as idols in hopes of summoning those benefits anew. The comparison to JWT is pre…

I'm disappointed. From your reputation and from having heard you speak on podcasts, I expected a bit more enlightening and friendly conversation than condescension and subtle insults. Regarding cargo cults around an opinion, consider this scenario: 1. Be a successful public figure in some domain. 2. Share opinion related to said domain. 3. People elevate opinion itself because of relation to successful individual wit…

What podcasts have you heard me on? I think I've guested on one in my entire life? (Podcasters: invite me!) You might have me confused with Marco Arment.

I don't think you've written anything else here that I haven't already responded to with the links I've provided or things I've written in this thread, and don't see much point in repeating myself.

Re: How to Use JSON Web Tokens

#118

Post by andrewstuart2 » Thu, Jan 03, 2019, 3:41 AM UTC

tptacek wrote: post #106

andrewstuart2 wrote: post #79

Earlier quoted context omitted.

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…

If you always have state, what's the point of making tradeoffs to get closer to "statelessness"? I see clearly why some small subset of applications benefits from carefully minimizing shared state among components. It is not at all clear to me why pseudo-statelessness is a good default .

I'm not sure you're actually asking for my opinion, or just making a point, but IMO, the "statelessness" most people describe with respect to web services simply means that a single request already has as much as possible of the information required (outside of current time, securely fetching/validating public keys, etc) to process the request.

The point is that it's easier for distributed systems as a whole when clients hold onto their client-specific state, rather than a minimal token that the server, likely being load balanced for availability, must exchange for that state with yet another service in yet another stateful/authenticated request/response manner.

Re: How to Use JSON Web Tokens

#119

Post by andrewstuart2 » Thu, Jan 03, 2019, 3:46 AM UTC

tptacek wrote: post #104

andrewstuart2 wrote: post #76

Earlier quoted context omitted.

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).

This is a little like saying "this is a problem you have with ANY identity solution that looks like JWT". Yes, that's true. The reason people complain about JWT is that (a) it's the most popular solution of this shape, and (b) people use it without understanding why they're using it or whether the tradeoffs work for their application. They usually do not. Witness everyone saying that the important feature of JWT is t…

Would you say then that confidentiality is always preferable to availability? I'm not quite sure how you'd achieve any sort of high availability over time without interoperability at some level. Presumably, if it has any place, that interoperability would belong at the lowest level of a protocol stack, with each successive level tuning acceptable parameters for their application.

Re: How to Use JSON Web Tokens

#120

Post by andrewstuart2 » Thu, Jan 03, 2019, 3:48 AM UTC

tptacek wrote: post #117

andrewstuart2 wrote: post #116

Earlier quoted context omitted.

I'm disappointed. From your reputation and from having heard you speak on podcasts, I expected a bit more enlightening and friendly conversation than condescension and subtle insults. Regarding cargo cults around an opinion, consider this scenario: 1. Be a successful public figure in some domain. 2. Share opinion related to said domain. 3. People elevate opinion itself because of relation to successful individual wit…

What podcasts have you heard me on? I think I've guested on one in my entire life? (Podcasters: invite me!) You might have me confused with Marco Arment. I don't think you've written anything else here that I haven't already responded to with the links I've provided or things I've written in this thread, and don't see much point in repeating myself.

Shoot. I've gone and mixed you up with Patrick McKenzie. If I remember correctly, he must have talked about your interactions a lot on that particular podcast. My mistake.