-
Notifications
You must be signed in to change notification settings - Fork 13
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
Encrypt generates corrupt signature #9
Comments
Are you saying that the I'm not sure what you mean by "classes assigned to claims" here either. |
The decrypt method works fine - but you never validate the token and therefore the signature is invalid. Take a look at the following code changes to see what I mean:
Basically, what should be happening is that the encryption should happen after the encoding vs. before the encoding because otherwise the signature is corrupted. Right now you can encrypt and decrypt but you cannot encrypt, and then decrypt and verify because the signature is no longer what the claims would have been. In the example above, this would change the implementation to work slightly different:
|
Ah, I see what you mean now - I remember this decision coming up. I ended up deferring to how some other libraries were handling this. It did make it difficult to do that token verification on the decrypt. So you're proposing adding the |
Not really, what I really propose is that:
|
For transparency purposes, node.js app for decrypting and verifying a token: This will show the error as the signature will not be valid. From that standpoint to fix it temporarily means off of the library I would do:
Although it still leaves a double base64 encoding on the decryption side :) |
I think part of the confusion here is where the encryption comes into play. Right now the encrypt/decrypt methods are trying to encrypt the claims themselves and not just use the OpenSSL stuff for the signature (much like this library does). From what I can tell in your example code, you're essentially wanting to verify that the encrypted token is correct. My library is a little mixed up on this right now, but I think I'm seeing a way out. The |
Okay, so i've pretty heavily refactored things. The hashing has been corrected and now signs with OpenSSL more correctly. I'm still working on the encryption (JWE) part, so stay tuned... |
When utilizing the encrypt method there are times when you want to decrypt and verify the token. Unfortunately this is not possible as the encryption passes the claims encrypted to the encode method. This causes a corrupt signature thus rendering the verification of the token useless.
There are a few different pathways to a solution here...
Other Thought and Better Approach
The library should likely treat decode and encode as a pre-processor and a post-processor. Meaning that they should only be run on a generated token. This would then mean the encode and decode have the responsibility of finding their area (aka claims by delimiter), and encoding the result from that standpoint vs. encoding the raw data. This would make it significantly more clean whilst not destroying the signature.
It would be up to the clients in this case to be able to understand how to decode the item.
The text was updated successfully, but these errors were encountered: