8000 scrutinizer-ci support, psr standards, more tests, and a change in the token format by mwillbanks · Pull Request #10 · psecio/jwt · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Closed
wants to merge 8 commits into from

Conversation

mwillbanks
Copy link

This fixes issue #9

The overall changes of the code are:

  • Update travis.yml for more php versions
  • Add in scrutinizer-ci support
  • Force psr standards with phpcs

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).

@mwillbanks
Copy link
Author

@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.

@mwillbanks
Copy link
Author

Assemble the final representation: The Compact Serialization of this
result is the string:

   BASE64URL(UTF8(JWE Protected Header)) || '.' ||
   BASE64URL(JWE Encrypted Key) || '.' || BASE64URL(JWE Initialization
   Vector) || '.' || BASE64URL(JWE Ciphertext) || '.' || BASE64URL(JWE
   Authentication Tag).

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.

@enygma
Copy link
Member
enygma commented Oct 3, 2014

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.

@mwillbanks
Copy link
Author

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.

@enygma
Copy link
Member
enygma commented Oct 14, 2014

Hey @mwillbanks, any update on this from the author you mentioned?

@mwillbanks
Copy link
Author

None... I think I might attempt to send an email to the mailing list or something.

@mwillbanks mwillbanks closed this Nov 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0