Differences between `SESSION_COOKIE_TTL`, `REFRESH_TOKEN_TTL` and `ACCESS_TOKEN_TTL`

Hello all!

I am looking for a technical clarification. I know some parts of this are present in the documentation and in some other topics here, but I don’t think any of those fully answer my question, which is actually quite practical:

Between those three TTLs (SESSION_COOKIE_TTL, REFRESH_TOKEN_TTL and ACCESS_TOKEN_TTL), how do they control browser-based access to the Admin front-end?

As a practical example: if I want to have a very long-lasting session TTL while the user is making operations, but as soon as they stop (for example close the browser or go to the toilet or whatever), the session should end shortly (say, 5 minutes).

Does this mean I can have something like the following?

SESSION_COOKIE_TTL = 4m
REFRESH_TOKEN_TTL = 5m
ACCESS_TOKEN_TTL = 4m

How would that compare to something like this?

Does this mean I can have something like the following?

SESSION_COOKIE_TTL = 4m
REFRESH_TOKEN_TTL = 5d
ACCESS_TOKEN_TTL = 4m

(Notice the much longer REFRESH_TOKEN_TTL). Does this mean that the session expires just the same, but I am then taken to the “reauthentication” screen that lets me just press “Continue” without entering a password, at any time within 5 days?

Thank you in advance for the clarifications, and thank you for the amazing piece of software!

That is very helpful, thank you! :slight_smile:

A longer REFRESH_TOKEN_TTL won’t give you a passwordless “Continue” screen. In both of your scenarios, once the 4 minutes are up, the user will face a hard login screen requiring their email and password. This happens because SESSION_COOKIE_TTL is source for a browser session. Once that time limit is reached, the browser automatically deletes the cookie. It doesn’t matter if the server-side refresh token is valid for 5 days; without the browser cookie to present to the server, the connection is lost. (Note: You do still want your REFRESH_TOKEN_TTL to be higher than the others to prevent race conditions during token rotation! - https://directus.io/docs/configuration/security-limits)

Regarding your “idle timeout” goal, you have to factor in how the Directus Admin App handles background polling. As long as the Directus tab is open and the computer is awake, the app silently requests new tokens right before your ACCESS_TOKEN_TTL expires, endlessly resetting your 4-minute timers. So, if a user walks away but leaves the tab open on an awake monitor, they will remain logged in. Your 4-minute expiration will only actually trigger if they close the browser tab or their computer goes to sleep (which stops the background script). If you need a strict timeout based on physical inactivity (e.g., no mouse movement), you would need to implement security protocols on the end devices to force sleep modes or similar functionality.