I wonder why this couldn't just be handled with two cookies, period: one a short-lived authentication token; one a long-lived revalidation token.
The former could be self-certifying (i.e., trusted if it's properly signed, with no auth service round-trip); the second could require a round-trip to the auth service). On a request, when the server see that the short-lived token has timed out, it checks the long-lived token; if still valid, then it reissues a short-lived token and sends it as a cookie value replacing the old short-lived token.
If multiple requests are in-flight, no matter — short-lived tokens require no session state, so all that happens is generating a few too many signatures.
The former could be self-certifying (i.e., trusted if it's properly signed, with no auth service round-trip); the second could require a round-trip to the auth service). On a request, when the server see that the short-lived token has timed out, it checks the long-lived token; if still valid, then it reissues a short-lived token and sends it as a cookie value replacing the old short-lived token.
If multiple requests are in-flight, no matter — short-lived tokens require no session state, so all that happens is generating a few too many signatures.
Am I missing something?