The risks I see are;

1. If the credential is revoked, the cache will continue serving a response that is no longer valid. The revocation cannot invalidate your cache, you would have to still check the validity of the cached data if you want to avoid serving invalid data from cache

2. Caches have many common issues that your code simply setting a value as you have shown do not address at all; poising can easily be achieved through he use of a deterministic key that is derived from a user's data, which an attacker can leverage and it isn't hard to observe with no knowledge of your source code (because it is so simple and very common)

3. Another is and cache stampede, you may have concurrent requests that come which will write to the cache and try to read before the first write persists so the second will also go fetch the source and try to save it too. There are many problems with not handling concurrency of keys and source lookups when a cache is leveraged and this issue makes the cache redundant entirely

4. when a permission is changed on the source, the cached credential may not carry that through until it has expired

5. an exploit on a client side will be able to masquerade as the user, and without validating the action until the cached ttl is reached you allow this to go unnoticed and the purpose of the auth validation you bypassed was to stop this exact issue

The risks I see are;

1. If the credential is revoked, the cache will continue serving a response that is no longer valid. The revocation cannot invalidate your cache, you would have to still check the validity of the cached data if you want to avoid serving invalid data from cache

2. Caches have many common issues that your code simply setting a value as you have shown do not address at all; poisoning can easily be achieved through the use of a deterministic key that is derived from a user's data, which an attacker can leverage and it isn't hard to observe with no knowledge of your source code (because it is so simple and very common the way you wrote it). The best case is they over-write a value with harmless data, the bad outcome is the value they write is malicious and served to other users (Stored XSS)

3. Another is a cache stampede, you may have concurrent requests that come which will write to the cache and try to read before the first write persists so the second will also go fetch the source and try to save it too. There are many problems with not handling concurrency of keys and source look up when a cache is leveraged and this issue makes the cache redundant entirely

4. when a permission is changed on the source, the cached credential may not carry that through until it has expired

5. an exploit on a client side will be able to masquerade as the user, and without validating the action until the cached ttl is reached you allow this to go unnoticed and the purpose of the auth validation you bypassed was to stop this exact issue