Decoding RS256 JWT about pyjwt

[cancan101]

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]

This might be related to #90

[cancan101]

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]

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

[cancan101]

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]

Interested in seeing a PR for this.

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

[mark-adams]

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]

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

[jpadilla]

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

[wbolster]

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