4 ms·

> 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'

> 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 conform (this protects against people making their own tokens with 'None' as the signing algorithm) People do this?? Why?

Freak_NL 8y ago
Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production. But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.
- tptacek 8y ago
  Most libraries do guard against this. But the point of a "standard" like JOSE/JWT is that you don't have to depend on a library; you should be able to consult the spec and build your own library. And, of course, alg:None is yet another pitfall that JOSE pointlessly opts you in to; it's yet another thing you need to know to safely implement JWT (it's far from the trickiest thing you need to know!)
smadge 8y ago
> 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.
- mattferderer 8y ago
  Both good points!
skywhopper 8y ago
Re 1), yes, it is the point, but it's not necessarily clear to everyone who looks at JWT as a solution to whatever problem they have. At a glance, a JWT looks like a binary blob. And there are cryptographic algorithms involved. So it's not a surprising leap for a newbie to assume JWTs are encrypted blobs. Introductory JWT texts rarely make this clear. Re 2), JWT libraries often make it easy to ask "is this token valid?" And I don't think it's unreasonable to think that "validity" means "signed by the shared secret I set in this library's configuration". But it usually doesn't. It usually means "this token is internally consistent". And since alg=None is a an option most people would probably assume would not exist, much less be counted as "valid", then it's not surprising that this happens. Basically, JWT's rendered format ensures it will be misunderstood and misused, so long as the available libraries don't enforce reasonable expectations. And from what I've seen, the library situation for JWT is pretty ugly, making a confusing standard even more confusing, instead of less so.

Freak_NL 8y ago

Libraries did that. Most now guard against this by forcing the developer to explicitly enable the 'None' algorithm. Normally you don't need it, and certainly never in production. But yeah, if your server accepts JWT's, reject anything that doesn't use an algorithm from your whitelist, which usually contains just one entry.

tptacek 8y ago
Most libraries do guard against this. But the point of a "standard" like JOSE/JWT is that you don't have to depend on a library; you should be able to consult the spec and build your own library. And, of course, alg:None is yet another pitfall that JOSE pointlessly opts you in to; it's yet another thing you need to know to safely implement JWT (it's far from the trickiest thing you need to know!)

smadge 8y ago

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

mattferderer 8y ago
Both good points!

skywhopper 8y ago

Re 1), yes, it is the point, but it's not necessarily clear to everyone who looks at JWT as a solution to whatever problem they have. At a glance, a JWT looks like a binary blob. And there are cryptographic algorithms involved. So it's not a surprising leap for a newbie to assume JWTs are encrypted blobs. Introductory JWT texts rarely make this clear. Re 2), JWT libraries often make it easy to ask "is this token valid?" And I don't think it's unreasonable to think that "validity" means "signed by the shared secret I set in this library's configuration". But it usually doesn't. It usually means "this token is internally consistent". And since alg=None is a an option most people would probably assume would not exist, much less be counted as "valid", then it's not surprising that this happens. Basically, JWT's rendered format ensures it will be misunderstood and misused, so long as the available libraries don't enforce reasonable expectations. And from what I've seen, the library situation for JWT is pretty ugly, making a confusing standard even more confusing, instead of less so.