JWTs giving HTTP 403 responses

Support
,
1

Hi,

We have been using JWTs on Tyk cloud for a little while now, and it worked pretty smoothly. As we’re still in our Proof of concept phase, I hadn’t touched the part that was using Tyk for a couple of days. When I now try to use the JWTs, every JWT I try results in a HTTP 403. Here more info:

When pasting the encoded JWT into: https://jwt.io/ and adding the secret, it validated correctly. When I then queried for the key in Tyk cloud, it gave me the right key, with the right access permission on the right API (+version).

The message in the 403 is:
{
“error”: “Key not authorized”
}

Any ideas on what might have changed on Tyk cloud, or where I could look further?

JWT details

Encoded token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjU2NzEzODc3NDgzNjY3MDAwMTAwMDBmYzcwNmZiZGNiYjJmZTQwYjU0YzI5MTcwMDNhZTcyZDBhIn0.e30.ptZA5UoSCn3GcyRjfJn5g9L_i77SS8wIb8Q_UtnSte0

Header:
{
“alg”: “HS256”,
“typ”: “JWT”,
“kid”: “5671387748366700010000fc706fbdcbb2fe40b54c2917003ae72d0a”
}

Payload:
{}

Verify signature:
HMACSHA256(
base64UrlEncode(header) + “.” +
base64UrlEncode(payload),

“80173f22-07ff-43e2-b947-ba467ab58bd9”
)

2

The short answer is that we introduced a check for base64 encoded sub or kid headers, the issue is, sub or kid headers that aren’t b64 encoded are still decoding (bug) and that causes the error.

short term: b64 encode the id, however we’re probably going to roll this back.

3

That roll-back is in place now, your JWTs should b working normally again.

4

Hi Martin,

thanks for the update, it is indeed working again. Where is the changelog for the original deploy?

Cheers,
Patrick

5

Hi Patrick,

It was a maintenance release to improve HMAC compatibility with legacy .Net clients, so no announcement or change log was posted. The JWT improvements were part of an ongoing experimental feature set that had an unfortunate side-effect of double-decoding kid headers.

Cheers,
Martin