-
Notifications
You must be signed in to change notification settings - Fork 13
scrutinizer-ci support, psr standards, more tests, and a change in the token format #10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…d but kept bc so it was not necessary
@enygma any interest here? :) In addition, I was looking through the spec for JWE which should be in the part of JWT and we are missing all of the encoding headers and such, in addition to that some of the random bits (https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-33#section-3.3) That might be by design, however, since we may not want to share that information as it would make it easier for someone to target specific attacks. |
Assemble the final representation: The Compact Serialization of this
So with JWT: http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#EncryptedJWTExample I have a question out to the author of the spec to understand the nesting level better. It is not entirely clear if the entire JWT token is encrypted OR if it is simply the claims. One would think the entire JWT token else it would be able to be verified. In this case I think the encryption and decryption part of this might need to be rewritten a bit and possibly separated out in order to do the nesting properly. Thus having JWT and then JWE as different items, likely with some form of helper glue in between. |
Yeah, there's interest...I just haven't had the time to dig into the proposed code and check it all out. It was my interpretation that only the claims were encrypted, but that may be my misunderstanding. I'd like to see what the author says on the matter. |
Same here, I looked pretty deep into it and it does seem the entirety of the token is encrypted and then tested stating that the type of contents is a JWT, but yet a JWT could be wrapped in a JWT and so forth. It would seem that that is the desired affect. I'll keep you posted because if that is indeed the case the method of encryption would need to be rewritten and a different approach taken all together. |
Hey @mwillbanks, any update on this from the author you mentioned? |
None... I think I might attempt to send an email to the mailing list or something. |
This fixes issue #9
The overall changes of the code are:
This is a BC break for existing tokens in the wild as they would need to be re-generated due to the encryption now happening in the proper area. Furthermore, we break BC by when utilizing decrypt it will now validate the token (which was not possible before).