JWT Parsing Failure - potential Base64 encoding issue

[lbusch25]

Branch/Environment/Version

• Branch/Version: Release v5.9.0, pulled in as part of the v4.0.0 helm chart
• Environment: On-prem hosting

Describe the bug
Upon upgrading to v5.9.0, our JWT fails to parse (we use Keycloak as our IDP and JWT provider, if needed for replication). Reverting to v5.8.6 solves the issue and the JWT parses as expected.

Messages from Tyk, in order:

• level=error msg="Couldn't get token" error="illegal base64 data at input byte 5" mw="JWTMiddleware"
• level=info msg="Attempted JWT access with non-existent key." mw=JWTMiddleware
• `level=error msg="JWT validation error" error=illegal base64 data at input byte 5"

Nothing in our environment has changed besides the Tyk helm chart, and associated Tyk version, upgrade. We've also managed to reproduce this issue with helm chart v3.0.0 and bumping Tyk to v5.9.0.

Reproduction steps
Steps to reproduce the behavior:

1. Add api using JWT based authentication
2. Add Security Policy
3. Send request to API

Actual behavior
JWT fails to parse. Reverting to v5.8.6 resolves the issue.

Expected behavior
JWT parses as expected.

Configuration (tyk config file):

api-config.json

security-policy-config.json

[probelabs]

Welcome & Initial Analysis

Hi @lbusch25, thank you for reporting this issue. Your detailed description and reproduction steps are very helpful.

Based on the error message illegal base64 data at input byte 5 and the fact that this is a regression from v5.8.6 to v5.9.0, our initial analysis points to a change in how JWTs are parsed. This is likely due to an update in a dependency that enforces stricter JWT specification compliance.

Technical Details

The JWT parsing library used by Tyk, github.com/golang-jwt/jwt/v4, was updated in a recent version (specifically v4.5.0 and newer) to use base64.RawURLEncoding for decoding JWT segments. This aligns with RFC7515, which specifies that Base64URL encoding without padding should be used.

The error you're seeing suggests that the JWTs generated by your Keycloak instance may include Base64 padding characters (=). The newer, stricter parser in Tyk v5.9.0 would reject these tokens, while the older version in v5.8.6 was more lenient.

Next Steps & How You Can Help

To help us confirm this diagnosis, could you please provide a sample of a failing JWT?

1. Inspect your JWT: You can decode your JWT using a tool like jwt.io. A JWT has three parts separated by dots: header.payload.signature.
2. Check for padding: Look at the end of the header or payload segments. Do they end with one or two = characters?
3. Provide a sample (redacted): If possible, could you share the first part of the token (the header)? For example: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. Please ensure you redact any sensitive information before sharing.

Additionally, it would be worth investigating if your Keycloak instance can be configured to omit the Base64 padding from its generated JWTs. This would make them fully compliant with the RFC and should resolve the issue.

We will keep this issue updated as we investigate options for handling this on the Tyk side for better backward compatibility.

Thank you again for your contribution!

---

Powered by Visor from Probelabs