Feature Request: Add support for encrypted tokens

[epelc]

Would there be any chance we can get support for encrypted tokens added? Or would this be something we should look for another package to do?

[dgrijalva]

It's possible. I haven't really looked at that part of the spec? Do you have a link?

[dgrijalva]

A recent JWT spec breaks tokens into signed tokens (JWS) and encrypted tokens (JWE). This library is designed for the former, but I'm looking into adding support for the latter.

[DisruptiveMind]

Would serializing the Claims into the payload be a good option? As in adding the Claims is the same process but we would just be doing something like token.EncryptedString in contrast to token.SignedString

[dgrijalva]

Encrypted tokens are defined in the spec I linked to above. We'll want to follow that. I think that's basically the idea, however:

• Encrypted tokens have more segments (5 vs 3)
• The additional segments are provided by the signing method (encryption method)? This likely means a new interface for encryption vs decryption
• The decryption flow may require a different interface, since there are more variable at play.

I need to fully read through the spec to figure out the impact on the APIs.

I don't have any use cases for encrypted tokens right now. It would be helpful if someone could point me toward some situations where these are used, so I can take them into consideration in the design.

[DisruptiveMind]

https://github.com/square/go-jose has some work on it. Some use cases listed here: https://tools.ietf.org/html/draft-ietf-jose-use-cases-06#section-5

I like to be able to just tuck everything away without providing any hints to the contents even when in transport. Or is this just counter-intuitive?

[kofalt]

@dgrijalva regarding a use case: A document that I read (maybe just the jwt spec?) mentioned things like Social Security Numbers as an example.

In my humble opinion, it's an insane idea to put something like an SSN on a client token (that is sent with every request) rather than securely exchanging that between systems anywhere but the browser.

My approach personally would be to do this "in userspace" by letting jwt-go handle the verification, then decrypting the Claim value myself. Just my 2 cents; how complex a spec-compliant implementation would be is left as an exercise for the maintainer :D

[dgrijalva]

Terrifying.

I think it's something we can add. I hope to be able to do it only additive changes to the API.

[kofalt]

Good to hear; that was my main concern (seeing as this has to process every request).

[kyleboyle]

@dgrijalva another use case in a blog post that just came out (2/3 down the page):

The use cases don't end there though. We could go one step further with JWT and make a user signup that creates a token with his registration inside the paylod. That way we don't have to temporarely store a user signup in a database. As an example, check out this token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoic29tZXVzZXIiLCJlbWFpbCI6InRlc3RAc29tZXRoaW5nLmNvbSIsIm5hbWUiOiJUZXN0IFVzZXIiLCJwYXNzd29yZCI6InVzZXJwYXNzd29yZCIsImNvdW50cnkiOiJJY2VsYW5kIiwiZXhwIjoxMzAwODE5MzgwfQ.QTDcx2GpbzVzfUpQ-QuFhuEgQEfAOa1V2meiAEUqnko
There is however one problem with the above token. It has the password the user typed in inside the token that can be easily decrypted, should someone get his hands on the token. However there are two solutions to this:

1. We can encrypt the payload and therefore nobody can read the data
2. We can have the password be typed in after verifying the email. The second makes the signup process a little more complicated as the user would have to type in some forms twice. The former however would simply work.

[DisruptiveMind]

Just wondering, would it be practical to just have the sensitive data encrypted as a 'data' claim for example?

The reason for this is to just have other 'public' claims available to the consuming application so it can too know when the token is about to expire, and other details but having things like SSN, user password, emails, etc all encrypted in a data object that is encrypted and stored as part of the 'data' claim in a JWT.

I'm just thinking more about a hybrid I guess.

[epelc]

@DisruptiveMind +1 I like the hybrid idea. But it'd be nice to support jwe by it self too.

[dgrijalva]

I believe JWE does support unencrypted fields of some sort.

[dgrijalva]

I started working on support for JWE. There's a lot of nuances to it, so it may take me a little bit. If someone else wants to take a crack, it might be faster. Otherwise, it's coming.

[dgrijalva]

Lots to do here. Looks like JWK is coming along for the ride here. Stay tuned.

[DisruptiveMind]

:+1: JWK

[sagikazarmark]

Any news?