Many of you have recently fired up your new Chromecast that you received over the holidays. I have to say I’m really impressed at how simple the Chromecast is to set up. Especially, how Chromecast automatically found my Google Play and YouTube content.
Think about this: Out of the box, Chromecast has no idea who I am, or what my available content is. In a few simple steps, I’m up and running with my content. I didn’t even enter my username and password! How did Google do that?!
The techie in me can’t resist trying to unravel the magic, so I dug in.
The answer turns out to be technically complex but simplified for the user by a well-designed installation app. The cornerstone of the magic is a protocol called oAuth 2.0, which we’ve worked with here at Cardinal Peak.
So what is oAuth? oAuth:
- is a standard authentication algorithm. Authentication is the process of validating that a user is who they say they are, usually facilitated by the presentation of credentials known to be associated with the user (username and password). Note that a user need not be a human. A user could also be other devices or web services. And credentials need not be a username and password. It could be a digital certificate or any number of other chosen elements. The trick is the authentication server has to know about the credentials and the credentials have somehow been validated against the user a priori.
- is employed by numerous large companies, from Google to PayPal to Twitter, allowing services and devices to pair with a user’s account and access their information and leverage hosted services on their behalf. Google provides extensive documentation, code libraries, and a fully functioning playground you can use to integrate an oAuth solution against.
- provides several different authentication profiles that can be leveraged according to your needs and environment. In the case of Chromecast, the oAuth 2.0 Device profile is being leveraged.
It turns out the technical mechanics of oAuth aren’t simple, but the key steps are summarized in the diagram below. (Here’s a larger version.)
As you go through the Chromecast setup, you may not see the login step, as was my experience on my Nexus 7. This is because my Nexus is already logged into Google and the Chromecast app just uses the login credentials the Nexus is using, so you don’t have to login again. This is a choice on the part of the app and Google, not a requirement of oAuth.
Now clearly this workflow is simplified (and actually a little out of order) but it describes the basic process and key steps of how oAuth works. In essence, the Chromecast is signing onto a well-known authentication server at Google. It obtains a device code from the authentication server and shows it to the user, Sue. Sue then logs into Google, who authenticates her using her username and password. Once Google knows it’s Sue, they ask for the device code. Behind the scenes, Google looks up the device code, validates it, and pairs the Chromecast with Sue’s account. Once the pairing has happened, the Chromecast is issued an oAuth token. From now on, the Chromecast can use this token as an abstract login credential of sorts to work on Sue’s behalf.
From the perspective of the Chromecast, the oAuth token is an arbitrary code that allows the Chromecast to perform tasks on Sue’s behalf, but not maintain Sue’s username and password and expose her to a larger security risk. If Sue’s Chromecast is suspected of being compromised, the token can be easily invalidated. Similarly, Sue can un-pair the Chromecast from her account and invalidate the token that way as well. The point is Google’s authentication server controls access, not the Chromecast.
So, Chromecast is learning all about my media library by simply asking Google for the information on my behalf. I just had to pair my Chromecast with my account to grant it access to my media and it took care of the rest. Perhaps not as magical as it first seemed, but the convenience is just as appreciated.