Pretty 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.

That'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.

1. This assumes that every page you might make the request to can issue auth tokens. This might be fine for small sites where auth isn't a concern (but then just issue a long-lived token and don't bother with all this), but for larger sites, capability to issue auth tokens is generally isolated from the rest of the services.

2. Your pseudo-code returns a legitimate short session cookie in response to gibberish. I'm hoping that this is just because you elided a lot of detail.

Co-author of the article here.

I agree with dpark - an unstated goal of this proposal was for developers to be able to easily move legacy sites with legacy endpoints to long sessions without needing to update those endpoints or pages.

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.

1. Why does every end-point being able to refresh a token (or whatever you want to call it) imply that auth must not be a concern? I will fully admit that I've never worked on really large scale web services, so hopefully that's not a super obvious thing.

I would think that having all pages be able to handle auth is just a architecture question. Maybe I've just been too deep for too long in writing a webserver in Iron [0], but the way you handle auth in it, by using middleware and wrapping any endpoint that needs auth with an auth handler, makes doing something like this trivial.

2. Definitely left out a lot, I mean it doesn't really return anything at all. Just meant it as some shorthand pseudo code to make explaining it shorter. :)

[0] https://github.com/iron/iron

EDIT: Actually now I'm not sure if you're talking server-side or client-side, but I think the argument still stands. I was assuming auth "tokens" could actually be cookies, but even if not, your API library just needs to have a check to see the the request returned updated auth. It's still just in one place, handled in all calls, rather than just the single call that would otherwise handle it.

I was referring to server side. If you're really serious about security, you probably want to isolate the login process to a dedicated server. If your web server is breached, do you really want your auth keys leaked? And do you really want access to your user's creds available en masse to the breached server?

If you're running a small scale service, you're unlikely to build a dedicated login service. If you're running a large scale service, you probably should.

Edit: Based on Thomas's answers here, I am wrong about this, so I guess take my thoughts with a grain of salt.

The 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.

Right, 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.