Support token compression about jwt HOT 3 CLOSED

There is one use case not considered: copy/pasting JWT. That's needed when JWT is generated on the web and human has to copy it to a local terminal, bootstrapping their client that talks to the server.

There could be another variation of the token so that compression wouldn't be part of the header. Compression probably doesn't have to be adaptive, since there's not much to choose from.

However, there is a challenge how to compress small-sized JSON into ASCII representation.

from jwt.

/cc @DASPRiD

from jwt.

After discussing this with @lcobucci, we came to the conclusion that compressing tokens is just not worth it. Specifically, for following reasons:

• when using JWT tokens in HTTP headers, HTTP2 already provides header compression
• token compression algorithm identifier would have to be stored in JWT headers, which makes most of the token non-compressible anyway
• tokens that are used as part of response bodies in HTTP requests/responses are already compressed by the user agent or the server
• tokens that are stored are unlikely stored as base64 encoded, as the JSON structure (and signature) makes it easy to convert the data into more optimized formats. For example, storing a JSONB object in a Postgres database can lead to amazing results
• tokens sent over the network can be re-coded into something else, if network impact and latency are relevant (for example, protobufs may be used)

Therefore, I'm closing this as "won't fix", as it really doesn't need a fix.

from jwt.