Google provides hundreds of web applications. Many are merged into its google.com domain, but most exist on their own domain like blogger.com or analytics.google.com. They want one mechanism to login across all web-apps for multiple reasons. The reason I would like to concentrate on, for this blog article, is the desire to be able to perform a lock-step upgrade of “accounts” for all web-apps. In order to achieve this they have not embedded core account logic in each separately released web-application. Instead they redirect from the web-app in question to accounts.google.com and back again after successful authentication, if the user is not logged in. If the user is logged into ‘accounts’ but not the web-app in question, the redirect to accounts and back again can be invisible.

Visiting a Google site with no pre-existing cookies.

Google’s Blogger site is a good place to examine here as it is fairly basic (sorry Blogger team!) in terms of technology. I’m using a Plugin for Firefox called HttpFox to show the sequence of GETs and POSTs from the browser’s point of view, but there are other ways of getting the same thing:

We are presented with the login page now. It is refers to Blogger as an ultimate destination because of a ‘service=blogger’ reference in the URL. When performing login on behalf of other google web-apps, it makes more of an effort to present itself as part of that app, by having more closely copied styling.

Anyway, assume we enter correct Google-Account details, and submit the form:

Note that the DQ-200CHARS-Ic ‘value’ is a shorter representation of something that is 204 chars long,

Visiting a Google site with pre-existing cookies.

table(table-striped){border-collapse: separate; border-spacing: 10px 5px; padding-bottom: 10px}. |. |. Arriving At |. Cookies? |. Consequence | |1|http://blogger.com| S=blogger=ssS7uFM-btx_UR5555Uo3w |redirect to http://www.blogger.com| |2|http://www.blogger.com| blogger_SID=DQ-200CHARS-Ic, S=blogger=ssS7uFM-btx_UR5555Uo3w |redirect to http://www.blogger.com/home| |3|http://www.blogger.com/home| blogger_SID=DQ-200CHARS-Ic, blogger_TID=cedf4444e637f4e0, S=blogger=ssS7uFM-btx_UR5555Uo3w | Page load|

Trying that again after deleting cookies .

Deleting ‘blogger_SID’ (204 chars) while away from blogger.com, then returning causes a redirect through http://accounts.google.com to reacquire the cookie.

Deleting ‘blogger_TID’ while away from blogger.com, then returning doesn’t cause a redirect back to google accounts, but does recreate a new value for blogger_TID (16 chars)

Deleting ‘S’ while away from blogger.com, then returning doesn’t cause a redirect back to google accounts, but does recreate a new value for ‘S’ (23 chars ignoring blogger= prefix)

Deleting all three cookies, then returning to blogger.com, causes a redirect through http://accounts.google.com to reacquire all three.

In terms of values, only blogger_SID (the 204 char one) is consistent. The other ones are regenerated each time.

What we have learned about Google’s auth cookies

The blogger_TID and S cookies contain keys that refer to something internal inside the Blogger platform. The blogger_SID key contains much more information about ‘me’ in the context of google accounts. I think it contains some personal information (my email address, whether I’m part of a “Google Apps For Your Domain” account in this context), and some context about when the authentication occurred, as well as a checksum. That cookie’s expiry is in 2019, so it isn’t part of the authentication (sensibly). The cookie’s payload, which I shortened from 204 chars to ‘DQ-200CHARS-Ic’, is encrypted of course.

As an aside, Google lost their private key for that in a hacking incident (a Windows user innocently installed a back-door or root-kit thing inside their MountainView campus) some years ago. They had to quickly invalidate all auth cookies everywhere, after choosing a new private key, after ensuring their deployment infrastructure was ‘safe’ as well as actually eliminating the back-door. I’d link to the article, but Google’s search isn’t finding it.

Architectural meaning of Google’s auth cookie design.

Blogger.com is going to get all three cookies for each request that comes in. Depending on the URL, that could mean for static assets like Jpegs and JavaScript too [See PS. below]. If the back-end Google application can decrypt the main ‘blogger_SID’ cookie (it can), and the checksum matches, it can trust the details within without referring to any account services internally as part of that transaction. If the backend decides that the cookie is wrong or missing, it will redirect through accounts.google.com. From the user point of view the redirect only happens once in a while. It’s hardly time-consuming anyway as Google apps are tuned for extreme performance for the most part. The redirect can happen when a timeout occurs - the cookie is decrypted and its internal not-valid-after has been exceeded. The redirect can also happen if someone in the security team has hit a “Untrust all auth cookies” button centrally, which probably pushes a signal to all stood-up application servers.

Here is the one-line summary - Google’s secure cookies for an authenticated user allow Google apps to save milliseconds not authenticating every request, while still having a strong centralized accounts service, and the ability to cancel cookies anywhere at any time.

If you are making multiple, separately deployable, sites for your enterprise, you should think about doing the same, instead of replicating a /accounts/Login.do in each application. Authentication is a special case though. Indeed Google is a special case though, as Steve Yegge lamented recently amongst other thoughts in a long piece. I’ll say some more about the general case for shared services in my next blog entry.

PS - I tried to convince the IETF team concerned with the cookie spec, that a useful change could be made. See my failure to do so on their mail-list (be sure to read the three replies to that thread) In the above case, after the page load, Blogger loads 15 static assets all of which receive the same three cookies but do not need to. Google are known for obsessing about unnecessary bytes, so I’m surprise they’ve not approached the IETF cookie steering committee.

Updates

Jun 14th, 2016: Note that this article says nothing about authorization (access controls). That’s a wholly separate concern to authenticaion, in my opinion. If you think it is a slam-dunk that the two should be co-located in the same canonical system, you’re mistaken. In my opinion, Blogger’s stack, after the redirect back, would make it’s own determination that authenticated user bgates@microsoft.com is a Blogger/Blogspot platform user or not, and do a different redirect than to “log in” if not.