We've detected what we think it's a bug in OTK (either 4.6.2 or 4.6.4) in the following scenario:
Have an APP with 2 certificates associated.
This is intended to have a window overlapping certificates to allow a client to switch from old close-to-expiring certificate to the new one, avoiding outage.
OK - Get CBAT token A bound to certificate A
OK - Invoke API with tokenA and correspondient certificate A
OK - Get CBAT token B bound to certificate B
ERROR - Invoke API with tokenB and correspondient certificate B. Invalid token
What we have seen is that the step 4 is bounding tokenB to certificate A if it's issued within 30 seconds after step 2.
And that is caused by the following cache (in the OTK Client Validation policy)
At that point, the correspondent variable mTLS_certificate_thumbprint holds the proper client certificate fingerprint but if the cache is valid (<30s) the value is overwritten with the fingerprint of the certificate correspondent to the previously emitted certificate.
11.1
This is a corner case which is valid bug. Broadcom will plan to address in future. This will require kid or some other field to be appended to cache key to make it unique.
In meantime, as a workaround. when they plan to switch to a new key, they can create a simple service policy to delete this cache by passing clientKey as shown below. This will clear the cache to ensure old key cache validations are removed. They can also add this as part of v2/token & disable after key is switched.