The JWT has to fit inside HTTP headers, which means it's not unlimited in size. The default header size limit varies by web server, but once you get above 8k it becomes a game of "which reverse proxy is choking on these headers this time?".
It's compounded by the fact that a lot of web servers (ie. nginx) have a global header size that limits all of your headers together, not just any one header, which means your JWT size limit is nondeterministic, especially if have large-ish cookies in your request.
There's standard ways to include the JWT in the request body, like form encoding, but that doesn't work for GET requests, so in practice everyone uses the Authorization header.
> There's standard ways to include the JWT in the request body, like form encoding, but that doesn't work for GET requests, so in practice everyone uses the Authorization header.
You can include a JWT as an access_token URL parameter, which works in a GET:
Ummm, every browser for decades has supported URL parameters. I can't believe that IE breaks with them.
Yes, large URLs are an issue, but not with search engines & access tokens, since search engines shouldn't ever see access tokens. A JWT should be lightweight — if it's big, then it's wrong.
> but not with search engines & access tokens, since search engines shouldn't ever see access tokens
It's like with the PHPSESSID URL parameter before cookie support was widespread. You can very well attach a session to a search-engine bot, and there are explicit hints for appdevs to do so.
You have to pass the tokens somehow, and search engines usually don't run JS.
> A JWT should be lightweight — if it's big, then it's wrong.
A JWT should replace sessions, and I have seen megabyte-sized sesion files on servers. People put an awful lot of stuff into sessions. Especially if application state is contained in the session. Oh, and if your application e.g. stores paths to files in the session and you switch 1:1 to JWT, you will leak server information to the client, which is a security hole.
...and then it goes and uses JSON, which is definitely not the most compact of serialisation formats. The whole thing is base64'd anyway, so something like ASN.1 PER which is a "true" binary format would be far better than base64'ing what is essentially text. But then, in my experience, Web standards tend to be weird like that.
