API's JWT Key Being Assigned to Wrong API

Support
1

Hello,

I noticed recently that there was some inconsistency with adding JWT keys to an API.

Here are the steps to reproduce (I have not been able to reproduce this consistently):

  1. Create the key in Tyk and assign to desired API.
  2. Used a valid JWT based off the Tyk key to hit an established route on the API.
  3. Received a 403 “Key not authorized” error
  4. Tried to proxy through a different API that was not assigned to the key, and it worked.

Also, the UI (key editing tab) does not accurately reflect the data - it says the key is associated to an API that it is not actually associated to; however, this is the API that I wanted it to be associated to when I created the key. To ensure that this was not a caching issue, I restarted both the gateway and the dashboard, but the UI still displayed the wrong API for the key.

I’m using the 0.9.7.2 version of the dashboard and a build of the gateway based off 8994e8578c20672d75fa785beadae3f9842acc6d.

Let me know if there’s anymore information I need to provide. In practice, I don’t think this bug will affect us, as we’ll be adding all of our APIs to a key, but FYI.

2

Also, when I hit /tyk/keys/?api_id=<id> the same set of keys shows up for all APIs, regardless of how I assigned them when creating them.

3

One more thing: I checked the Redis database, and the API key is indeed associated to the right API; however, I cannot use it to access established routes on this API - only on another API that I did not associate to this key.

4

The API ID param sets the back end to use, it is not a filter. That is expected behaviour (it’s odd I know, but Tyk has the capability to have a different storage back end for auth and session on a per API basis, which means we need to kneel which backend to query)

5

Are you using a policy here or manually assigning API’s to keys?

Policies overwrite key data when it comes to access rules. Which would explain both issues:

  1. The key working on a non assigned API (if the policy allows it, it’s ok)
  2. The key data looking odd, the policy has overwritten the key permissions data
6

What would really help is the gateway log output around when the key is blocked.

7

Hi Martin,

Thanks for the info and quick reply! We are not using any policies.

I started a new organization from scratch to test:

  1. I added a new API (api1) with JWT authorization.
  2. Tried to access the API with a valid JWT, but got the aforementioned 403 error.
  3. Created a new API (api2) with JWT authorization and did not add any new keys or update the existing one.
  4. Was able to access api2 with the preexisting key.

Here is what the gateway log prints when I attempt to access api1:

INFO[54770] Attempted JWT access with non-existent key. key=56aa391e509a9949820000018c98458bde58469d4bba6e81ab558bd8 key_present=true origin=10.40.9.164:50319 path=/posts/ ERRO[54770] Token validation error: Token invalid, key not found. WARN[54794] Invalid key detected, not found in storage engine INFO[54794] Not found! ERRO[54794] Couldn't get token: Token invalid, key not found.

There is no gateway log output when I access api2.

8

I just tried to replicate this with the latest version of develop and I can’t, tried the same approach:

  1. Create two APIs with JWT (HMAC)
  2. Create a key with a shared secret and specific access rights to API1
  3. Save the key
  4. Use the token to generate a JWT with this
  5. Set the sub header to the Key that was generated in Tyk
  6. Make requests with Postman To API 1 (10/10 successful, no bounces)
  7. Make requests with Postman to API 2 (10/10 fail rate:
{
    "error": "Access to this API has been disallowed"
}

It might be the commit version you are using, which might have been buggy. It isn’t replicable now in HEAD (the risk of bleeding edge) :slightly_smiling: