Token Compression Algorithm
whichperson opened this issue · comments
Describe the problem you'd like to have solved
I have a huge problem where the access token is so long, the server rejects the HTTP requests. I use this library to generate access tokens. These tokens have a large amount of information (e.g. more than 100 user authorities in the form of a string). It is impossible to remove this information to make the token shorter. I'd prefer not to use a different library (like jjwt which has token compression), this one is actively maintained.
Describe the ideal solution
Add a token compression algorithm. I think this is a simple enough feature to add as existing libraries already have it implemented. I've also noticed other people need it.
Alternatives and current work-arounds
Use a different library. Much appreciated!
Additional information, if any
@whichperson The reference you are saying seems to be library-specific and not a generic standard. We usually try to keep our features compliant with the RFC-7519. Do you have any resources that point to a standardised implementation of this?
@poovamraj
Gzip compression is standard in Java. You can compress/decompress a String with this algorithm. It's in Java's docs https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/zip/GZIPInputStream.html.
Hi @whichperson though Gzip compression is a standard compression algorithm. JWT compression is not part of RFC 7519 which this library follows.
RFC-7516 seems to have a provision for compression but that is for JWE.
Even the library you mentioned seems to call out that it is non-standard and wouldn't be supported by other libraries. I think adding non-standard features would be wise at this point.
What I can suggest though is instead of compressing the token. You can do GZIP compression of all your authorities and then put the result as a claim value. This way your JWT will continue to be compliant with the standards.
We will keep an eye out for this in the standards but I don't see us taking this feature now. So we are closing this issue. Sorry about that.