Back in May, I wrote about Client Certificate Authentication, a mechanism that allows websites to strongly validate the identity of their visitors using certificates presented by the visitor’s browser.

One significant limitation for client certificate authentication is that there is no standards-based mechanism for a user to “log out” of a site that uses that auth mechanism.

Background on Auth Caching

When a user picks a client certificate to authenticate to a server, that choice (an {Origin, ClientCert} tuple) is remembered for the lifetime of the browsing session. Any subsequent CertificateRequest challenge from that origin will automatically be answered by the browser using the previously-selected certificate.

The Auth Caching behavior is necessary for at least two reasons:

• User-Experience: Client Cert authentication is a connection-oriented authentication protocol– each connection to the server can challenge the user for a client certificate, and the browser re-prompting the user for a new certificate for each new connection would be incredibly annoying.
  
• Predictability: Even worse, if the user accidentally picked a different certificate for subsequent connections, the browser would end up in the very confusing state whereby requests might exhibit different behavior based on which reused connection happened to be pulled from the browser’s connection reuse pool when each request is sent.

Unfortunately, tying the Auth cache’s certificate selection to the browsing session means that if a user has multiple certificates, selecting a different certificate for subsequent use on the site (either because the user chose the “wrong” certificate the first time, or because they would like to switch their “identity”) is not generally straightforward.

The only option that works reliably across browsers is to restart the browser entirely (closing all of your other tabs and web applications).

Log Out Approaches

To address the user desire to “Log out without restarting,” Internet Explorer offered a “Clear SSL State” button buried inside the Internet Control Panel:

… and websites could invoke the same functionality with a web-accessible JavaScript call:

 document.execCommand("ClearAuthenticationCache", false);

Notably, the button and the API both clear all Client Certificates for all sites running in the current session, meaning users cannot log out of just a single site using the API.

The ClearAuthenticationCache API was not standardized (and a blunt hammer with many side-effects), so it was not supported in other browsers.

Instead, the standardized Clear Site Data (MDN) offers a mechanism for websites to programmatically clear per-origin data including Auth Caches (both HTTP Authentication and Client Certificate Authentication). Unlike the IE ClearAuthenticationCache call, Clear-Site-Data is per-origin, so calling it does not blow every site’s data away.

Unfortunately, it’s not very useful for logging users out of Client Cert auth’d sites, for a few reasons:

1. Websites cannot clear only Auth caches– the Auth caches are instead cleared when the website indicates that it would like cookies cleared.
2. Websites cannot clear only Session data– when you request that cookies be cleared, it clears not only the Auth caches and session cookies, but also clears the origin’s persistent cookies.
3. Clearing the Auth Cache alone isn’t enough– the browser also must clear/close any authenticated connections to the origin from the reuse pool, because otherwise a request might reuse a connection previously authenticated with a client certificate.

   The complexity and side-effects of this requirement mean that Chromium has not implemented the clearing of the Auth cache when Clear-Site-Data is called.

Chromium also does not offer any UI mechanism to clear auth caches, meaning that users must restart their browser to clear the auth cache and select different credentials.

Sessions vs. Profiles

Beyond the Clear SSL State button and ClearAuthenticationCache API, Internet Explorer offered users a New Session command that allows a user to open a new browser window that runs in a different Session than the original — the new browser window’s Session does not share Session state (the auth cache, session cookies, sessionStorage) with the original Session. The new Session does however share persistent state (persistent cookies, localStorage, the HTTP Cache, etc), so the two Sessions are not fully isolated from one another.

In contrast, Chromium does not offer such a “New Session” feature. Users can have a maximum of two active Sessions per profile– their “main” Session, and one Private Mode (“Incognito”) session. If a user wishes to have more than two Sessions active at a time, they must load the site using multiple Browser Profiles.

My many measures, this design is “better”– using a different Profile means that all state is isolated between the instances, so you won’t have localStorage, indexedDB data, persistent cookies, or HTTP cache information cross-contaminating your different browser sessions. You’ll also have a handy Profile Avatar in your browser UI to remind you of which account you’re supposed to be using for each window.

However, to an end-user, using different profiles might be less convenient, because profiles isolate all state, not just web platform state. That means that Favorites, Extensions, History and other useful application state are not shared between the two Profiles.

There are a variety of investments we might consider to address this use case:

1. Enhance Chromium’s Clear Site Data feature to match the spec. (The fact that this got punted in Chromium suggests that it’s a hard problem)
   
2. Offer the user an explicit mechanism in the browser UI to clear an origin’s Auth cache and empty its connection-reuse pool. (Users will have to learn the new mechanic)
   
3. Try to be clever and clear the Auth cache when the user closes the last top-level browser tab to an origin. This is not quite as crazy as it sounds; there have been some discussions of this approach to address the problem of undead session cookies. (Tricky to implement this without undesirable side effects)
   
4. Implement something like Firefox Containers to allow one Browser Profile to contain multiple isolated Web Platform-level sessions/profiles. (Expensive, Complicated, Users will have to learn the new mechanic)
   
5. The clever and simple solution for this longstanding problem that I simply haven’t thought of yet.

Given the relative obscurity of this scenario, I’m hoping #5 turns up. :)

-Eric