10 ms·
A practical proposal for migrating to safe long sessions on the web
- cpeterso 10y agoYou don't necessarily need to authenticate every request. For example, Amazon.com allows a user to be "semi-logged in", but forces you to authenticate yourself when doing something like making a purchase.
- projectramo 10y agoI just hope that that other tabs cannot see the cookie within a tab. Or if there was some other way of isolating identity. My concern is privacy.
- sp332 10y agoIt's just a cookie. It works like every other cookie.
- projectramo 10y agoYeah, but I mean before they implement this scheme, I hope they modify the browser (or someone comes up with one), so that you can pick which group of cookies are accessible within different tabs. With apps, I know that this app doesn't know my identity from that app unless I explicitly give it permissions.
- jerf 10y agoFirefox is working on it, you can try it in the nightlies, at least as of this post: https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ https://blog.mozilla.org/tanvi/2016/06/16/contextual-identit...
- projectramo 10y agothanks.
- merb 10y agoactually a cookie is still only accessible if its on the same origin or on a subdomain of the origin.
- projectramo 10y agoI did not realize that. If that is so, why is Firefox working on the tab-cookie isolation (see other answers).
- sp332 10y agoThis is mentioned in that blog post, but data is separated by a tuple of: (scheme e.g. HTTP or HTTPS, domain, port). Any page from one such set cannot access cookies, local storage, indexeddb, or cache from a page with a different set. The new feature simply adds one more attribute, so even if pages share scheme, domain, and port, they will not be able to read data from a site with a different userContextId.
- merb 10y agothats more to seperate work and private data. I.e. at the moment you can't login to Office 365 twice. With a tab isolation level it would work. But actually its more like a container which you can assign to multiple tabs. you could start a tab with the container private or with the container xyz
- sp332 10y agoFirefox is starting a project on this, it's still in research stages though. https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ https://blog.mozilla.org/tanvi/2016/06/16/contextual-identit... In the meantime, you can use different user profiles in Chrome or Firefox, but they work per-window not per-tab.
- projectramo 10y agoGreat news. Thanks. Didn't realize that Chrome and Firefox do that on a per-window basis. I browse everything in incognito mode.
- mcculley 10y ago> 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. I wish that were true more often. There's a handful of native apps that don'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't looked into it further because I don't have my Google password memorized; it's a randomly generated password that I expect my computer to remember for me. It seems like every native IoT widget controller I try wants me to remember more credentials.
- NickBusey 10y agoGet a password manager that syncs to your phone. I'd be completely lost without it. I love 1Password for syncing. Just pop it open, copy/paste, done.
- j_jochem 10y agoI use KeePassX and Keepass2Android, with the database file stored on Dropbox. It's free and runs natively on Linux.
- StavrosK 10y agoSince upvotes are invisible, I will comment to say I second this. Keepass2Android is a amazing and I love this solution, even though I've always otherwise hated password managers.
- mcculley 10y agoI'm aware of these options and use LastPass. My issue is that I shouldn't have to copy and paste at all. These apps should be using system services for this (e.g., the Keychain API on iOS).
- Kequc 10y agoI've explored this in the past. Wouldn'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?
- sp332 10y agoBut if the user resets their password, it should log out all the user's sessions. But you have to wait for the cookies to time out before they are re-authenticated. (Or make a check on every request to see if the password has been changed, which is just a pain.)
- bryanlarsen 10y agoYou don't check on every request to see if the password has changed, you check to see that the session is valid on every request. You should be doing that anyways. Then all you have to add is a way for password changes to invalidate the session.
- azdle 10y agoThe thing is that the way that a session is usually "validated" these days is to just store a userid in some serialized format then encrypt that and send it off as a cookie that expires in a relatively short amount of time (and hopefully put the expire time in the encrypted message too). Then the server just has to try to decrypt the cookie and if it results in a valid userid then the session is valid. This way you don't cause an extra database request for every user request. I'm not saying it's good or secure, but it's the way I often see it done/suggested to be done.
- Kequc 10y agoI figure if you need to re-issue or initially issue the two cookies you set one of them to expire after 6mo and the other 1yr.
- ddalex 10y agoOr you can just forget about the cookie on the server side - you don't need to expire anything.
- mattbroekhuis 10y agoSo is this like oauth2 refresh token?
- bryanlarsen 10y agoNote that the article buries a much easier way to deal with this problem: "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)" 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're done. There are very good reasons for doing that anyways, so no need for this hack.
- mountaineer22 10y agoWould there ever be a reason to have the cookie expire at all? If the password is changed, you can invalidate the session, but the cookie remains?
- jessaustin 10y agoThe point is that verifying on the server can be a pain. TFA's proposal avoids doing so, much of the time. One could imagine rolling out any number of parallel "service workers" to perform this task without needing to complicate the server with concerns about a single user's requests hitting multiple servers that therefore need to stay on the same page with respect to token revocation.
- ddalex 10y agoThe session has to be fetched from cache/hot memory on every request, right? Authenticating the session per request may be expensive, but actually clearing the session cache so the request can't even get the session data - that's much better. So you don't need to invalidate the auth tokens. You just need to be able to delete a session from the cache to do revocation on long sessions. And this works with just backend changes, no client hockey-pokey needed.
- mark242 10y ago"The session has to be fetched from cache/hot memory on every request, right?" Nope. Let's say you have a rest endpoint that accepts a Pokemon id to add to your collection. If you cryptographically sign a cookie that says "I am this user id" you can assume the request to add the Pokemon to your collection is valid. There's other business logic to perform, sure, but "I am this user" is taken care of for you. What Google is proposing is the ability to save a long-term cookie that says "I am this user" and a short-term cookie that says "I'm signed in". The requests periodically say "am I still signed in/am I still this user" and the server can periodically (eg not every request) look that up in cache/database.
- merb 10y agoThat'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. 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.
- azdle 10y agoI don't really understand what the service worker that makes an extra network request adds here. 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're currently handling?
- edvinbesic 10y agoPretty much this. Especially if you are already using promises in your library, having an async function that returns the token to you solves that problem. Now you don't have to worry about where your token comes from, if it immediately resolved or if it had to do a round-trip to refresh the token etc.
- mark242 10y agoThat's the other option; sending both session cookies at the same time and having the server do the work. Google's solution pushes that "if (short_session != valid)" logic to the client vs having it run on the server.
- adregan 10y agoThe benefit of the service worker is that they can intercept all fetch events and would allow you to move validation code out of the thread that is running the UI. It can make for a simpler client, but really it's just shifting the complexity to another layer. However, there are a lot of potential benefits to service workers (eg. caching, background downloads, notifications—tho possibly a negative) so perhaps the added complexity is ok.
- azdle 10y agoRight, but I'd really doubt that "store new auth token if it exists in response" would take long enough that it causes any kind of problem. I know that there are benefits to using service workers in general, I guess I was just thinking about it in terms of adding a service worker to an application that isn't currently using them just to do the handshake they're suggesting. In which case it would be a lot of added complexity and wouldn't work across the board, whereas doing the check on the server side would add very little complexity and would work with every browser made since about 1995.
- zeveb 10y agoI 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
- kiliancs 10y agoIn 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.