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 l

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.