Auth0 access token cannot proceed with JWE encrypted payload without decryption parameters about jwx HOT 9 CLOSED

This seems like a similar problem. Read the last response: https://community.auth0.com/t/auth0-access-token-is-missing-the-jws-payload/71674/5

from jwx.

You are using v1?

from jwx.

So I noticed I was using v1 and switched over to v2. Thankfully, I'm not getting the same error. However I'm now getting a new error:

6:39AM ERR error="failed to find a valid token in any location of the request (tried: [header keys: \"Authorization\"]). Additionally, errors were encountered during attempts to parse headers: ([header key: \"Authorization\", error: \"unsupported format (layer: #1)\"])"

from jwx.

Right, I think you are using v1.

In v1, we tried to work with messages that looked like JWE(JWS(payload)) or JWS(JWE(payload)) gracefully. In hindsight this was silly, so it has been removed as of v2.

In v1, the heuristic for determining the message type is done in jwx.GuessFormat. There are a bunch of reasons why jwx.GuessFormat would think that the payload is JWE, but here are some of those:

1. The payload contains 4 "."s
2. The payload contains the field "ciphertext" after base64 decoding is done.

It is extremely rare that you would find the field "ciphertext" in your payload, so I would assume that you have a payload that does not look like JWS.

Without seeing the actual payload, that's all I can say, really.

from jwx.

So the error message says that it tried looking for the JWT payload inside Authorization header, and couldn't parse it. Did you check if you have a proper JWT payload in the authorization header?

from jwx.

So this is the header...

authorization: Bearer eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM6Ly9kZXYtbnloNWk0MDcudXMuYXV0aDAuY29tLyJ9..vv7RwXbIMuqoE9Bs.BtdlzXAp3W_lFre0wbmeOahQLyyq7BFLdyagAj1udNPk6RqHnb9tpXC34XApbptEtee-mHJgG-djSJBrr3Ky1Ngq43YxIhJjZ87E1BV9h-8-qpR5j49Y4hLDRGSelVtegjye9Zb2qQM73DZaeL9T9ChnEgMoziV07MqM_dqF4l51d73_UPnAIYjNthVhVrpYzsMahhJDJEoevBT63AH0JH3GHQ6GcwNhqVbDslNfwz63DhV_vEK35ot6tXCRHPc6RM62FfocsjoyogDdWgdTD8uM1w9Ok3WI83zd3CCBws4naFuVJs7WIX6Ot920ydm6hISNvHZdSpUoYN71Eky0rFUEkx79-fxKGgKZoDllV5K5KEwXPYA2h60kxfAKjbeLWKSx1nd4HIRdpcoDAWWGzy-CSg.XVcURxNxx5obO9YpDue44Q

It's the Auth0 access_token. Another library is able to parse this token using the rsa.PrivateKey generated from your library, so I'm unsure why this wouldn't be working. Let me try extracting the header and feeding in the bytes to Parse to see what happens.

from jwx.

Wait a sec... that's odd. That JWT token has four segments. This is the token I'm receiving from Auth0...

from jwx.

Before going any further, this is definitely wrong:

And I do see 4 dots, so it definitely looks like a JWE encrypted message. In which case it would be syntactically valid to have two consecutive dots there, because that just means it's an empty protected header.

I have no clue about Auth0 and its access tokens, but it just feels wrong.

from jwx.

Unreal... three hours wasted. Thank you for sending that over. Not providing an audience returns an encrypted payload.

THANK YOU!!!

from jwx.