You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
We get a 403 error with 'No matching KID..." on token that are created with newly created keypair that is not in the cache. Usually after 1 minute or 2, the cache will be invalidated in tyk and this token will be validated successfully.
Reproduction steps
Steps to reproduce the behavior:
Add api and continue JWT with jwksSource
Run the first request and Tyk will make call to get the keys and it'll cache it
Create a new jwt token with a new keypair and call the api with this token (Note must be within 4 minutes as this is the max configured in Tyk jwt cache)
The request will fail with 403 status code
Actual behavior
The request will fail with 403 status code
Expected behavior
If the key is not present, Tyk should invalidate the cache and go to jwkSource to get a updated key before failing the request
Screenshots/Video
If applicable, add screenshots or video to help explain your problem.
Logs (debug mode or log file):
Log from console or from log file.
Branch/Environment/Version
Describe the bug
We get a 403 error with 'No matching KID..." on token that are created with newly created keypair that is not in the cache. Usually after 1 minute or 2, the cache will be invalidated in tyk and this token will be validated successfully.
Reproduction steps
Steps to reproduce the behavior:
Actual behavior
The request will fail with 403 status code
Expected behavior
If the key is not present, Tyk should invalidate the cache and go to jwkSource to get a updated key before failing the request
Screenshots/Video
If applicable, add screenshots or video to help explain your problem.
Logs (debug mode or log file):
Log from console or from log file.
Configuration (tyk config file):
Attach tyk configuration file
Additional context
Another possibility is to expose the ability to disable the cache in the jwt middleware. This is currently hard coded as seen here
The text was updated successfully, but these errors were encountered: