Skip to content
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

Decoding RS256 JWT #93

Closed
cancan101 opened this issue Feb 17, 2015 · 10 comments
Closed

Decoding RS256 JWT #93

cancan101 opened this issue Feb 17, 2015 · 10 comments
Labels

Comments

@cancan101
Copy link

I am trying to decode a JWT encoded with RS256.

When I run the following:

secret = Crypto.PublicKey.RSA.importKey(PUBLIC_KEY)

I get:

ValueError: RSA key format is not supported

I suspect something might be wrong with the public key format:

PUBLIC_KEY= """-----BEGIN CERTIFICATE-----
MIIDETCCAfmgAwIBAgI....sRPdPR8
-----END CERTIFICATE-----"""
@cancan101
Copy link
Author

Following this to get a :

-----BEGIN PUBLIC KEY-----
...
-----END PUBLIC KEY-----

and then setting this to JWT_SECRET_KEY seems to do the trick.

@jpadilla
Copy link
Owner

This might be related to #90

@cancan101
Copy link
Author

The issue is mentioned here: https://cryptography.io/en/latest/hazmat/primitives/asymmetric/serialization/#pem and also talked about in #82.

The solution is to load the certificate using:

key = cryptography.x509.load_pem_x509_certificate(PUBLIC_KEY, default_backend()).public_key()

rather than:

 key = cryptography.hazmat.primitives.serialization.load_pem_public_key(key, backend=default_backend())

@jpadilla
Copy link
Owner

Still not clear with this if there's something we can do to prevent this confusion.

@cancan101
Copy link
Author

You could make this logic try to fall back one to one more attempt. You could add some additional logic to look for the begin/end public key string as well.

@jpadilla
Copy link
Owner

Interested in seeing a PR for this.

@wbolster @mark-adams I'd love your thoughts on this.

@mark-adams
Copy link
Contributor

I think we should update the documentation to indicate how to load a key from an x509 certificate.

I don't think adding more fallback logic is the right approach. The API expects a key and it works when you pass in a key. A certificate is way more than a key so it's a bit outside the scope of our code and would only add complexity.

It should be the consumer's responsibility to make sure they are passing in a key and not something else. If we do something like this, why not check to see if it is ZIP compressed, or embedded in a Word doc, or maybe a reversed string? :)

@cancan101
Copy link
Author

I would say more important than the fallback logic would just be documentation.

@jpadilla jpadilla added the docs label Feb 22, 2015
@jpadilla
Copy link
Owner

Sold! If anyone wants to take a stab at that, pull requests are welcome.

@wbolster
Copy link
Contributor

+1 on having this as documentation. Adding magic detection logic to the jwt API isn't the right way imho, as @mark-adams pointed out.

jpadilla added a commit that referenced this issue Mar 17, 2015
Resolved #93 by adding a section the README detailing how to extract public / private keys from an x509 certificate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants