Configure gateway to accept header with compressed JWT token value

[edwinames]

Hi,

I'm new to the Apigee Edge Gateway. I'm modifying an existing system that passes a JWT token in the authorization header. We are using the hosted solution -- we don't have access to host server. Our JWT tokens are getting too large. We would like our clients to compress the tokens. The gateway will need to decompress the authorization token before any other processing.

I am currently considering a custom policy to decompress the incoming authorization header. Considering using the gzip js library. Looking for best practices around handling incoming compressed headers.

If I end up coding the decompression myself, I would prefer to use the gateway's gzip js library rather than uploading our own. Is this possible?

Thanks!

[dchiesa1]

What problem are you really trying to solve?

What do you mean when you say, "our tokens are getting too large" ?

The beauty of the JWT format is that each JWT is self-verifying and can contain distinct claims. The downside of that is that JWT can be large, because all of the claims are directly encoded in the JWT itself.

Compressing the JWT is one possible way to mitigate the size, but ... you won't compress very much. Practically speaking, you will reduce the JWT to maybe 50% of its original size. (Just a guess) The signature itself will not be compressible, because it is random data. Supposing your JWT is 384 bytes, the signature might be 170 bytes of that! Maybe you could compress the remaining 210 bytes, but...what is the net? Still you will have a JWT of over 200 bytes.

Would it be a benefit to you if, instead of passing the JWT with *all of the claims*, you could pass an opaque token that was maybe 32 bytes, and that could be used by Apigee Edge to *refer* to all the claims?

That way your clients would send 32 bytes instead of the full JWT encoding?

This is possible in Apigee Edge. For example, see here.

If you want to know more, let me know.

[edwinames · Accepted solution]

@Dino-at-Google Thanks for your response. Our JWT tokens are getting large enough that the request header size exceeds our server default sizes. Basic testing agreed with your estimates on compression, we found a max 70% size reduction on our JWT claims. We will not pursue compression. For now we are configuring our servers to accept larger headers. Longer term we will look at some kind of scope mapping, quite possibly a client-level scope identifier and might well use your approach.