OIDC Key Expired Error

Support
, ,
1

Hi - I’m having OpenID Connect problems similar to those found here but it wasn’t clear what the resolution was.

I’m using Tyk Cloud as a quick way to test out Tyk for our project - in particular, we need to be able to handle OIDC authentication from multiple IdPs. I played with something in Tyk cloud using Google and a test local Keycloak server (using the same by-hand procedure as described in the Integrate with Open ID Connect document); I was pleased at how quickly it worked yesterday, but today - getting ready for a quick demo to colleagues - I get “Key has expired, please renew” errors when authenticating with either IdP.

The word key seems to be used multiple ways in the project, so I’m not even sure which Key has expired here - it’s not the OIDC id token, so it’s the… IdPs JWK? Something else? - and so I’m at a loss as to how to proceed.

Any suggestions?

Following up - it does appear to have something to do with “Keys” getting “stuck” for users - authenticating in as a different user seems to proceed correctly. But creating one-off identities isn’t much of an option for my use case, so I’m still blocked on this.

2

The issue will be wcause the policy associated with the original user has an expiry set. If you remove the expiry from the policy it should work again.

If that doesn’t work the internal cached key that represents the user will need to be purged from redis.

3

How does one go about setting a policy for OIDC tokens for users one hasn’t seen before, so this doesn’t happen again? And for cases where it has happened, how does one best go about purging the key from redis in the Tyk cloud?

4

For OIDC you will be binding the client ID against a policy ID. So that takes care of all users for a specific client application.

Just set the policy to be unlimited - Tyk will respect the expiry set on the JWT itself so then you can handle token rotation entirely in your IDP.

As for purging old keys - that’s a bit trickier :slight_smile: have you tried just updating the existing policy?

5

Thanks, Martin! That doesn’t seem to work, though.

Right now if I manually go in on the cloud dashboard and try to edit the key to set the expiration policy, I can set Key Expiry to “Never” in a dropdown menu, but there doesn’t appear to be any button to save the result; leaving the page and then going back verifies it hasn’t been changed.

There’s a big “delete” button, but it only reports that it can’t delete the key, which isn’t very helpful.

On the Key config page it does say that the expiry is being set by a policy. But under Policies, the only existing policy, which I created for the OIDC client, does have something about “Trial period (Set key expiry on create)”, but that had already been set to never. Just in case it hadn’t been, I deleted the old policy, created a new policy with that set to never expire, re-set the OIDC authentication policies with the clients to the new policies, but I’m still getting “Key has expired, please renew”

With the new policy existing, I can go back to the existing keys, set the policy to the new policy, and it encouragingly says “Key Expiry values are being overwritten by [new policy] Policy” with key expiration is set to Never, great: but again I can’t seem to update & save the key, and so re-visiting the page again says that it’s expired some time ago.

Because it’s not clear to me what Key means in this context and what it’s used for, I’m not even sure it’s true that I want the key to never expire, or even be long-lived - does this just refer to just some internal representation of the user? I’m not sure what the advantage is of having a default setting where users are able to log in initially and then never again after some expiry date?

I’m happy for there to be no Tyk internal representation of the user ever, I can handle that on the services’ side. Is this just something for Tyk Pro and the dashboard - that is, if I’m just using Tyk CE can I avoid all of this?

Are there any suggestions as to how I proceed to give a demo using Tyk + OIDC for my colleagues?

6

Tyk uses an internal representation of the user to track rate limits and quotas across subsequent JWTs. It uses the Tyk “key” mechanism to achieve this - it’s essentially an internal token that represents the subject claim.

If you can access this key (it will be a short hash) then all you need to do is delete it, Tyk will recreate it based on the associated OIDC client policy with the new expiry time set to never for the internal token (this is fine to never expire, because Tyk will always first validate the JWTs expiry.

7

Hi, Martin:

Great - thanks for the explanation! Unfortunately, I can’t seem to delete the key? As I mentioned before, all I get is “Could not delete key”.

Is there an option outside of the cloud dashboard to do so? \

8

Ah, hashed key editing may be disabled in cloud. There’s two ways:

  1. You generate the original raw key yourself - I believe it’s your org ID + b64(sub) and use the dashboard api to delete it

  2. We do it for you - could take a while though

9

Ok, I’ll give that a try. Thanks!

10

Hi Martin,

We’ve run into a similar issue on our deployment.

As suggested we set our policy key expiration to “Do not expire key”.

From what I’ve read and observed the OIDC token to internal Tyk key mapping is based on the username in the JWT. No problem there…

The problem arises when we need to update a policy (we add an API for example).

At this point we are hosed. We have the Tyk key sticking around with stale policies. We have been able to manually delete:

curl --header "x-tyk-authorization: 12345" -X DELETE https://api.all.the.things/tyk/keys/bce9c01c?hashed=true

This isn’t really manageable at any scale.

Is there any sort of flush / delete all the active keys capability? We’re ok that we would lose state on quota. The access policies as you might imagine are of primary importance.

Thanks much

-Michael

11

upgraded to 2.6.1 and set "enable_hashed_keys_listing": true,

It’s not pretty, but we can manually script the flushing of keys/sessions on policy updates.

Thanks!