Monday, November 03, 2014

X-Auto-Login at Google

Below you can find evidence that Google is using the X-Auto-Login header in production.
Please see my other post for context:
 I am using "wget" to get gmail web page and the HTTP response contains the X-Auto-Login header.

I think that Google should standardize this.
Currently Google is using OpenID2 here but it is probably ease to standardize this with OpenID Connect.

ignisvulpis@namenlos:~/mozilla-central$ wget -S --user-agent="Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36"
--2014-11-03 12:23:50--
Connecting to connected.
Proxy request sent, awaiting response... 
  HTTP/1.1 302 Moved Temporarily
  Content-Type: text/html; charset=UTF-8
  Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  Pragma: no-cache
  Expires: Fri, 01 Jan 1990 00:00:00 GMT
  Date: Mon, 03 Nov 2014 11:23:51 GMT
  X-Content-Type-Options: nosniff
  X-Frame-Options: SAMEORIGIN
  X-XSS-Protection: 1; mode=block
  Server: GSE
  Alternate-Protocol: 443:quic,p=0.01
  Connection: close
Location: [following]
--2014-11-03 12:23:51--
Connecting to connected.
Proxy request sent, awaiting response... 
  HTTP/1.1 200 OK
  Content-Type: text/html; charset=UTF-8
  Strict-Transport-Security: max-age=10893354; includeSubDomains
  Set-Cookie: GAPS=1:lAGQAL021CeF4UofSLjbzRnvJw_Eqw:256mW0v3ZoeLVjLo;Path=/;Expires=Wed, 02-Nov-2016 11:23:51 GMT;Secure;HttpOnly;Priority=HIGH
  Set-Cookie: GALX=xATUIfBPIN4;Path=/;Secure
  X-Frame-Options: DENY
  Cache-control: no-cache, no-store
  Pragma: no-cache
  Expires: Mon, 01-Jan-1990 00:00:00 GMT
  Transfer-Encoding: chunked
  Date: Mon, 03 Nov 2014 11:23:51 GMT
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Server: GSE
  Alternate-Protocol: 443:quic,p=0.01
  Connection: close
Length: unspecified [text/html]

2014-11-03 12:23:51 (1,44 MB/s) - ‘mail’ saved [70172]


Friday, September 12, 2014


Maybe you are an Android user and wondered how sometimes the browser logs you in without asking for a password?

Well, I wondered but never found the time to investigate.

Thanks to the awesome W3C Web Cryptography Next Steps Workshop and thanks to the usual jet-lag I found that time now. First I thought that this is Google-ism "Chrome does some questionable proprietary trick and knows just how to login to Google accounts". That is half-true.

There is chatter on the chromium list but I seems that the Android browser knows this trick since 2011 and Chrome for Android was released in 2012.

So how does it work?

  1. a site responds with a special HTTP header "X-Auto-Login" 
  2. the browser sees that header 
  3. the browser asks the device's account system for local accounts for the realm parameter of the header (e.g. 
  4. the browser asks for a special kind of token from that account 
  5. the browser asks the user for consent to login 
  6. the token is an URL - so if the user consents the browser opens that URL 
  7. the site the URL points to accepts the token 
  8. the site redirects the browser to the original page the user wants to use


I think this is neat. But why doesn't Google talk about it? Why isn't this standardized at W3C?
Anyway. How can you benefit?
As a user? You already do.
As a website with your own mobile app?
  1. Well, Google is probably not issuing tokens for your site. Maybe they do or would do because they want to be an identity provider?... 
  2. Issue the tokens yourself.
  1.  What you need on the Android device is an AccountAuthenticator.  
  2. let your website issue the X-Auto-Login HTTP header "realm=com.yourdomain&args=..." 
  3. let your Account Authenticator from step a generate tokens based on 'String authTokenType="weblogin:" + args;' 
  4. let your site accept the tokens generated by your Account Authenticator

I think this is a good idea. If your company has an mobile app then build that Account Authenticator. This is even more true if your company has several mobile apps. (Put the authenticator in your own CompanyServices.apk (like Google does with the GooglePlayServices) so you can update independently from your apps.)

You might know that I work for a 100% subsidiary of Deutsche Telekom. Why isn't DT doing this? Don't ask me. I am telling them for years that our own AccountAuthenticator would be "gold". But who listens to me. Working for a big company has its challenges.

Back to wondering... How can we get this or something similar standardized through W3C?

Maybe I should write a blog post to make it more known. But then who reads this blog anyway. ;-)

Thanks for listening.

Tuesday, February 18, 2014

Web Identity Restart?

Well, how can you restart something that never started? ... Never mind.

I am wondering whether it makes sense to have a W3C workshop on "Internet Identity" again.

My impression in 2011 was that the common ground was not very broad so the group decided to launch the W3C WebCrypto working group because all agreed that crypto is a precondition to web identity. Now, three years later I do not see much progress in web crypto or web identity (for that matter).

In the meantime the FIDO alliance was established which has HW-based authentication but a license model that requires that implementers are a FIDO alliance member. That is the opposite of a web standard.

So I think that the WebCrypto WG will not give us "identity for the web". Signing/verification/encryption/decryption are too low level and too easy to use wrong. This is not the way to web identity.

Maybe it is time to restart the web identity effort in W3C.