Add gzip compression option for the JWT Claims part

[szank]

No description provided.

[bbrks]

👍 for compression support, but I'm reluctant to support a breaking change to token.New()

Maybe a token.NewCompressed() or something? And let the old one internally default to jwt.CompressionNone

[elithrar]

Do any other major JWT libs do gzip compression of claims? (out of
curiosity!)

On Tue, Dec 15, 2015 at 5:43 PM Ben Brooks notifications@github.com wrote:

[image: 👍] for compression support, but I'm reluctant to support a
breaking change to token.New()

Maybe a token.NewCompressed() or something? And let the old one internally
default to jwt.CompressionNone

—
Reply to this email directly or view it on GitHub
#102 (comment).

[bbrks]

jose-jwt and its various ports (jose2go, jose.4.j) support deflate out of the box. But not gzip.

[elithrar]

I'd just be cautious about actually gzipping claims—the spec doesn't say
you can't, but the spec is reasonably prescriptive and doesn't say you can,
either ;)

Importantly though, what browser-based gzip libs exist for decompressing
the claims, and are those performant on mobile?
https://github.com/nodeca/pako looks solid but focuses on node
benchmarks/examples.

On Tue, Dec 15, 2015 at 5:55 PM Ben Brooks notifications@github.com wrote:

jose-jwt https://github.com/dvsekhvalnov/jose-jwt and its various ports
(jose2go https://github.com/dvsekhvalnov/jose2go, jose.4.j
https://bitbucket.org/b_c/jose4j/wiki/Home) support deflate out of the
box. But not gzip.

—
Reply to this email directly or view it on GitHub
#102 (comment).

[bbrks]

To be fair, you could just compress any huge byte slices before you put it in the JWT. And decompress when you want to use the data. This has the advantage of sticking to the spec whilst giving you a huge compressed blob to consume.

(using ridiculous never-in-the-real-world sized sample data)


[szank]

First, I agree, that adding a new method and not breaking the existing API could be better. I wanted to see what @dgrijalva would say about it, but it seems that he is taking a break from github right now :).

Also, gzipping the claims is not enforced. We use JWT in a RESTful application, the claims won't be read by the client, only by the server which have created them in the first place. It is useful only in such restricted use case, but we are not trying to make everyone happy here anyway.

Also, yes, I can gzip my data before passing it to JWT, but I try to contribute some useful changes to the upstream if I can. I rather have it done in JWT, makes the code cleaner and more reusable.

[dgrijalva]

Why not just compress the whole blob?

[dgrijalva]

It seems the right place to add a feature like this would be in the spec. Though, there are several other ways to implement this without violating the spec.

• If all clients are going to treat the token as an opaque string, you could just compress the whole token and stick that in the header.
• For a more forward looking approach, SPDY (HTTP/2) supports full header compression, making this moot.

For this library, I'd be most comfortable with making compression possible with an external add on. I'd like to adhere to the spec as much as possible, without closing doors for users to do what they'd like.

[AlmogBaku]

this may break older versions of the token

[AlmogBaku]

@dgrijalva how can you make this as an addon? by implementing a wrapper encryption method?

[dgrijalva]

Here's a function that will compress and re-base64url encode the content. Because of the double encoding, the content ends up being larger. This may not hold true for larger tokens. Give it a try and let me know what you think?

func compressedToken(s string)string {
    buf := new(bytes.Buffer)
    enc := base64.NewEncoder(base64.URLEncoding, buf)
    wr := gzip.NewWriter(enc)
    wr.Write([]byte(s))
    wr.Close()
    enc.Close()

    return string(buf.Bytes())
}

[dgrijalva]

Unless this gets added to the spec, I don't think its inclusion is wise. If you need new hooks allow you to accomplish this outside the library, let's have that discussion instead.

[Ocramius]

Just poking back here: regardless of the spec, we came to the conclusion that most mediums for storage or transfer of JWT tokens are already supporting their lower-layer compression (before filesystem or network interaction).

Ref: lcobucci/jwt#82 (comment) (just to provide arguments, should this come up again)

[asambeka]

Compression is part of JOSE specs on IANA, reference: https://www.iana.org/assignments/jose/jose.xhtml and also RFC 7516.
Header parameter: zip
Supported values : DEF (Deflate from RFC1951)

@szank @dgrijalva : If the change mentioned here is restricted to zip header with Deflate algorithm, it will be compliant with specs and will achieve the objective (i.e. compression).