Short lived tokens
Closed this issue · 4 comments
We need additional guidance on batch or long-lived sessions - more than 30% of workloads run for more than 5 minutes and not solving for them is problematic. One approach is to remove the requirement on short lived or leave it to the implementor to decide what short lived means, Another is to recommend the use of standards like SSF/CAEP as a mitigation for long-lived tokens where the security properties matter.
Agreed that we cannot have a token lifetime that won't meet the needs of a significant number of workload requests. We need a recommendation in the spec though in order to mitigate replay attacks. Just curious: In the "30% workloads > 5 minutes" statement, are we talking about a process that handles multiple requests, or 30% requests lasting more than 5 minutes?
I don't have that detail about the data point. From personal experience, I have seen batch jobs run for hours (23-24 hours in some cases).
Will it not cause security issues If we keep the tokens active for a longer time in a batch job where someone internal can access those tokens?
Even in long lived batch jobs, individual RPCs will be short-lived. The external authorization token that impersonates or delegates authority from users can be long lived, in order to generate new Transaction Tokens