title: Transparent user session over several sites (single sign-on + single sign-off)
body: <p>I have several sites in different domains: <code>example.com</code>, <code>example.org</code>, <code>mail.example.com</code>
  and <code>passport.example.org</code>. All of the sites are having common look-and-feel and
  should share the same user base.</p>
  
  <p>And in such extreme case I still want all the sites to <em>transparently</em> (as much as possible)
  share user sessions with the following key properties:</p>
  
  <ol>
  <li><p><strong>Single sign-on</strong>. When user signs on at <code>passport.example.org</code> and visits
  any other site — he should be treated as logged in.</p>
  
  <p>Logged in users get “Hello, <code>$username</code>“ greeting in site header and different
  navigation menu, listing services they have access to. If he's not signed in, instead
  of greeting there's a “Sign on” link, pointing to <code>passport.example.org/signon</code>.</p>
  
  <p>The list of trusted domains is known, so this is fairly simple to implement either
  with OpenID or with some homebrewn lightweight protocol. When user first hits the
  site, I'm redirecting him to special authentication endpoint at <code>passport.example.org</code>,
  which then silently redirects him back, with identity information (or “not signed on”
  anonymous identity) included. For most browsers this is completely transparent.
  Obviously, I'm using nonce values to fight redirection loops.</p></li>
  <li><p><strong>Single sign-off</strong>. When user clicks “sign off” in the header of any site
  the next time he visits any site — he should be seen as “not sign on”.</p>
  
  <p>OpenID was not designed for this. My current idea (I already have a partially-working
  implementation) is to send not user identity, but “global” session token and share
  global sessions table (global_session_token ↔ user relation) in DB.</p></li>
  <li><p><strong>Robots and cookieless-users support</strong>. Sites are having public areas, which should
  be accessible by user-agents without any cookie support.</p>
  
  <p>Because of this, redirection I've mentioned in (1) becomes a problem, because for
  every single page request, I'll end up throwing user-agent to auth endpoint and back.
  Not only this will confuse robots, but it will pollute my session database with
  dead-on-birth sessions very quickly. And I definitely don't want to display “hey,
  you don't have cookies enabled, go away!” page, that'd be extremely rude and
  disappointing. While I require cookie support to login, I want users to freely read
  what the sites are for and so on — without any restrictions.</p>
  
  <p>And I explicitly <em>don't</em> want to put session IDs in URLs except for some transparent
  cross-domain redirections I've mentioned. I believe doing such is a security problem
  and just generally a Bad Thing.</p>
  
  <p>And here I'm almost out of ideas.</p></li>
  </ol>
  
  <p>Okay, I know this is hard, but Google actually does this somehow with (<code>google.com</code>,
  <code>google.</code><em>lot‑of‑gTLDs</em>, <code>gmail.com</code> and so on), right? So this should be
  possible.</p>
  
  <p>I'd be grateful for either protocol description ideas (that'd be the best) or links
  to systems (either code to read or just live sites to watch and learn upon) already
  successfully implementing something like this.</p>
  
  <p><strong>To sum it up:</strong> Several domains without common root, shared user base, single sign-on, single sign-off, no cookies required to browse anonymously.</p>
  
  <p>All of the sites are on the same network (but rest on different servers) and partially
  share the same PostgreSQL database (resting in the different schemes of the same database).
  Most of sites are written with Python/Django, but some of them are using PHP and Ruby on Rails. While I'm thinking of something framework- and language-agnostic, I'm grateful for pointing to any implementations. Even if I won't be able to use them, if I'll get the idea how it's done there maybe I'll be able to come up implementing something similar.</p>