Security review wants shorter-lived user tokens, what does CROCT_TOKEN_DURATION control?
Hello, our internal audit flagged all long-lived authentication artifacts in the stack, and the Croct user token came up in the list. Before I change anything I would like to understand the mechanics precisely.
Could someone clarify what CROCT_TOKEN_DURATION actually changes, and how it relates to the ct.user_token cookie lifetime? They seem to be two different knobs. Also, is there a sensible lower bound before things start breaking?
Thank you in advance, I want to bring exact numbers back to the auditors
1 answer
They are two different knobs, and you can report them separately:
-
CROCT_TOKEN_DURATION sets the lifetime of the issued user token itself, in seconds. The default is 86400 (24 hours). Token issuing happens server-side using CROCT_API_KEY, which is also why that key requires the "Issue user tokens" permission.
-
The ct.user_token cookie is the carrier for that token in the browser. It lives 7 days by default, and its lifetime is configurable separately through the cookie options if the audit wants that shortened as well.
The proxy manages the ct.client_id and ct.user_token cookies internally, so shortening the token duration is purely a configuration change: no application code touches those cookies directly.
For a lower bound, keep the duration comfortably above your typical session length so tokens are not reissued excessively. Values in the range of one to a few hours are a common landing spot for stricter policies.