Hi all, Can someone help me investigate why I'm getting an 'invalid claims' error for my JWT in my test/development environments where I'm not getting the same error in my production environment?

curl --request GET \
  --header "Authorization: Bearer $signed_jwt" \
  --header 'Content-Type: application/vnd.gooddata.api+json' \
  $HOST_URL/api/v1/profile -v
Note: Unnecessary use of -X or --request, GET is already inferred.
* Host <http://pushoperations-test.cloud.gooddata.com:443|pushoperations-test.cloud.gooddata.com:443> was resolved.
* IPv6: (none)
* IPv4: 54.225.116.104, 34.202.40.188, 52.70.92.108
*   Trying 54.225.116.104:443...
* Connected to <http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com> (54.225.116.104) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=<http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com>
*  start date: Aug 16 11:45:52 2024 GMT
*  expire date: Nov 14 11:45:51 2024 GMT
*  subjectAltName: host "<http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com>" matched cert's "<http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com>"
*  issuer: C=US; O=Let's Encrypt; CN=R11
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for <https://pushoperations-test.cloud.gooddata.com/api/v1/profile>
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: <http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com>]
* [HTTP/2] [1] [:path: /api/v1/profile]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
* [HTTP/2] [1] [authorization: Bearer [REDACTED]]
* [HTTP/2] [1] [content-type: application/vnd.gooddata.api+json]
> GET /api/v1/profile HTTP/2
> Host: <http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com>
> User-Agent: curl/8.7.1
> Accept: */*
> Authorization: Bearer [REDACTED]
> Content-Type: application/vnd.gooddata.api+json
> 
* Request completely sent off
< HTTP/2 401 
< date: Mon, 09 Sep 2024 18:16:47 GMT
< content-length: 0
< vary: Origin
< vary: Access-Control-Request-Method
< vary: Access-Control-Request-Headers
< www-authenticate: Bearer error="invalid_token", error_description="The JWT contains invalid claims.", error_uri="<https://tools.ietf.org/html/rfc6750#section-3.1>"
< cache-control: no-cache, no-store, max-age=0, must-revalidate
< pragma: no-cache
< expires: 0
< x-content-type-options: nosniff
< strict-transport-security: max-age=63072000; includeSubDomains
< x-xss-protection: 1; mode=block
< referrer-policy: no-referrer
< 
* Connection #0 to host <http://pushoperations-test.cloud.gooddata.com|pushoperations-test.cloud.gooddata.com> left intact

Hello Tim, checking the logs I located the error

Signed JWT rejected: Another algorithm expected, or no matching key(s) found

. It’s pretty self-explanatory, indicating that either there’s no JWK matching the Token, or that the algorithm on the Token doesn’t match the one used on the Key. I understand the JWT auth already works on your prod environment; Are you using the same Key pair on Dev/Test? Or did you generate different ones for these domains? Was the same setup completed on these other domains?

Hi Francisco! I used the same key pair, and registered the JWK with GoodData in the same method. Calling the JWK endpoint for -dev and -test I get the expected result with the correct algorithm returned.

I don’t think that would be a problem - they are separate and there are no checks for this kind of thing that I’m aware of. So it should be OK to use the same JWK; Did you generate a new JWT for the key, though?

Yes, we generate a new JWT during the user's session with our test environments pointing towards our test GoodData environment.

How is the JWT generated? Is it done via JS, as per our Example Article? I would recommend comparing both the Keys and process through which the tokens are created on both environments; If nothing shows up, I’d recommend creating and trying out a new JWK, to ensure that the point of failure isn’t there. 🙂

It's using the Firebase library in PHP, but a similar process. In the command line instructions, the key ID corresponds to the key that's registered but in the javascript instructions (and what I had working in production), it uses the "kid" field. If I send a request using the KID, I get a different error message: "We are unable to verify signature."

Yes, now the errors are different; I can see

Signed JWT rejected: Invalid signature

, which does indicate that the Token hasn’t been signed properly. Have you tried decoding the JWT on https://jwt.io/ or similar tool, checking whether they are valid, and comparing the results to the JWK?

If I re-generate new keys and JWKs it seems to work. Not sure why that would be the case without some kind of block on key re-use somewhere along the line.

I’m glad to hear that the full re-creation made it work. I will check internally and let you know whether that is indeed a limitation or if it was something else!

Okay, thanks for checking! Ya, I think I followed all the same steps and the new keys and JWKs are working.