A practical proposal for migrating to safe long sessions on the web

Note that the article buries a much easier way to deal with this problem:<p>&quot;some websites don’t verify the user’s authentication on each request (i.e. there is no way to revoke the session cookie once issued)&quot;<p>Which implies that if you do verify the session on the server and have a mechanism for invalidating these sessions on password change, etc, you can just use very long cookies and you&#x27;re done.<p>There are very good reasons for doing that anyways, so no need for this hack.

I wonder why this couldn&#x27;t just be handled with two cookies, period: one a short-lived authentication token; one a long-lived revalidation token.<p>The former could be self-certifying (i.e., trusted if it&#x27;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.<p>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.<p>Am I missing something?

I don&#x27;t really understand what the service worker that makes an extra network request adds here.<p>Why not just have the code that validates the session just do an `if (short_session != valid) { lookup_long_session_in_db() }` then return a fresh short session cookie with whatever request you&#x27;re currently handling?

&gt; We all love how native apps will ask you to login only once and then remember you until you tell them you want to log out.<p>I wish that were true more often. There&#x27;s a handful of native apps that don&#x27;t remember my credentials and I have to go look them up on the desktop in my password manager. For example, I installed Pokémon Go but haven&#x27;t looked into it further because I don&#x27;t have my Google password memorized; it&#x27;s a randomly generated password that I expect my computer to remember for me.<p>It seems like every native IoT widget controller I try wants me to remember more credentials.

You don&#x27;t necessarily need to authenticate every request. For example, Amazon.com allows a user to be &quot;semi-logged in&quot;, but forces you to authenticate yourself when doing something like making a purchase.

That&#x27;s what we did except that the short lived token is a GWT no in a Cookie. While the Long Lived Hash is a Cookie with a database. But the Cookie will only live for the session of your browser. Mostly we only query the database every 5 minute, cause of that.<p>Actually we also have a workaround to support Safari by trying to put stuff in LocalStorage that tells the other Tab that it recently got a new token and so on.

So is this like oauth2 refresh token?

In the long run it would be better to find a standard way of doing this so that browsers implement it without the need for a worker initiated from JS. Static pages could benefit from safe long lived sessions as well.

I&#x27;ve explored this in the past. Wouldn&#x27;t it be possible to simply set two 1yr cookies one at the mid-expiry point of the second. Then re-set the first when it expires and vice versa?

I just hope that that other tabs cannot see the cookie within a tab. Or if there was some other way of isolating identity.<p>My concern is privacy.