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?