Overview:

With the introduction of refresh token rotation (RTR), access tokens (aka AT or Okapi Tokens) expire after a configurable amount of time (referred to as the AT TTL). Both Okapi-based and Eureka-based platforms support RTR. However, the AT TTL is set to a relatively short 10 minutes in the rancher/snapshot envs running Eureka, and the hosted reference envs are currently setup with much longer AT TTL (1 hour?). This had led to situations where QA identifies a problem in one of the Eureka envs which turns out to be related to RTR, they’re unable to reproduce it in the hosted reference envs (because the AT TTL is much longer), and so they determine that the issue must be Eureka-specific. In at least one case that has been proven to not be the case. Operating in this way, where the burden is on the Eureka team to triage, troubleshoot, and prove that the issue is not Eureka-specific is creating a bottleneck and slowing things down. In order to improve this, it would be great if we could have consistency between the Eureka-based and Okapi-based envs wrt the AT TTL (and ideally the RT TTL as well). From my perspective 1 hour AT TTL is long enough that it effectively hides these sorts of problems (e.g. with modules caching tokens for later use, etc.). The purpose of choosing a short AT TTL is that in the event that an AT is compromised/stolen, it’s only good for a short period of time. Think about what you could do in 10 minutes, vs what you could do in an hour… An hour provides attackers with a much larger window in which to execute their attack (data exfiltration, etc.)

Acceptance Criteria:

• At least one of the two folio-snapshot sites are configured with an AT TTL which aligns with the kitfox-managed Eureka-based snapshot environments. (10 minutes)

  • Ideally Refresh Token TTLs are also consistent (1 hour). Here I think a higher value is likely to be used in production environments, but using a shorter value in our snapshot envs will give us a better chance of finding RTR-related issues.