3 ms·
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 co
by zeveb 10y ago
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.
Am I missing something?
- sesm 10y agoI second your question. The only downside of sending both cookies on each request is a bigger request size, which is not a bad trade-off for much simpler client (no service workers, everything is managed by cookie jar) Also, the approach with 2 cookies (statefull + stateless) is known for a long time. Eran Hammer (author of OAuth1 and OAuth2 specs) wrote about using this approach at Yahoo here: https://sideway.com/room/4Z https://sideway.com/room/4Z (search for Yahoo).
- StavrosK 10y agoIsn't the original problem that someone could steal the long-lived cookie in the first place?
- true_religion 10y agoThe long term cookie requires authentication from a service (e.g. maybe a database backed session), and the service can invalidate a particular cookie on logout, or by user request.
- crashedsnow 10y agoThe intent is not to provide an "unstealable" token, but a revocable one. You can't (don't need to) revoke the refresh token but you can revoke the access token by disallowing refresh.
- deleted 10y ago[deleted]
- owencm 10y agoCo-author of the article here. An unstated goal (we probably should have stated it, looking back) was for sites to be able to easily move legacy sites with legacy endpoints to long sessions. The service worker approach can effectively intercept requests to any endpoint and perform the re-generation of a short cookie if needed, without needing to change every page on the site or the legacy endpoints. One additional benefit is that it minimizes the transmission of the long term token, which is generally good if you're worried about it somehow getting intercepted. You may or may not be too concerned about that risk though.