You can include a JWT as an access_token URL parameter, which works in a GET:
https://foo.invalid/bar?access_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQOnly works with IE > 11, and even IE 11 breaks down sometimes. Also, search engines choke on large URLs, see http://stackoverflow.com/a/417184/1933738
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.
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.
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.