Some devices want to access a user's data, but do not have the ability to display a full web browser. For example, think of devices like an Tivo unit displaying Netflix videos or connecting to a Pandora radio account.
One of Google's challenges is that Google exposes lots of APIs such as Photos, Health, & Ads. So we want to allow the app to request access to just a limited set of scopes. And for some of those scopes (like Health), we even need the user to choose the access level and profile. Many OAuth SPs do not need to support that level of complexity, so in those cases there are simpler approaches that can be used.
For Google, in the "fridge display private photos" example, our team had suggested something like the following (though other approaches might work for some devices, and the OAuth 2.0 community is debating specific standards for some of these approaches that Facebook is supporting and which Google intends to support).
1) Device/app starts the OAuth dance and also requests a PIN from Google which Google will associate with the OAuth request token
2) After the device/app gets the OAuth request token, it tells the user (or its manual tells the user) to visit a short URL (like fridgephoto/register). The device then displays the PIN they will need, and says to come back and click a button on the device when they are told. If the device cannot display the PIN, then the device manufactuer might do step 1 before shipping the device to the user, and then provide a printout of the PIN in the set of instructions provided with the device (similar to the license keys printed on Microsoft Office installation CDs).
3) The user goes to a web browser on another device, like their personal computer, and opens that site. The site is a static HTML page that gives some introductory help text, and a link to Google's site to do the authorization.
4) When the user clicks the link, they are sent to Google with the URLs parameters for the scopes that device/app needs, and a Continue URL back to that site, as well as a URL param indicating the user has a PIN
5) They are then sent through the standard Google OAuth approval process. If the user has not yet logged in, then they will need to do so (and this might involve a redirection to a SAML/OpenID IDP and/or use of a strong auth mechanism like a USB token)
6) Once the user is logged in, they see a standard Google OAuth approval page with information about the claimed app, the scopes, and any advanced controls such as to pick access level or a profile. Assuming the user clicks okay, they are then asked to enter the PIN. Google confirms the PIN is a valid outstanding one, and then the user is redirected to the continueURL (like fridgephoto/authzdone)
7) That device/app's site displays a static HTML file that tells the user to go back to the device/app and click a button to indicate they finished the approval process
8) The user click's the continue button on the device/app
9) The device/app then finishes the OAuth dance
Note that an “evil” hacker could request a lot of PINs from Google, and hope that a user mistakenly types a PIN that is associated with a “hackers” request token, thereby giving access to the user’s data. As an extra layer of security, we can send the user an E-mail after an OAuth approval that used a PIN, with the "claimed identity" of the app, and provide a single link the user can click to deactivate that OAuth token. If the user does more then one approval for the same claimed app in a short period of time, then on the OAuth approval page we might even give a warning that the previous one might have been "hijacked" and give them an easily way to deactivate any recent OAuth tokens issued to the same claimed app.
Optimization for users that have a mobile phone with QR code-reader
An optimization for the user experience can be implemented for market segments where it is likely that the user has a mobile phone with a web browser and QR-code reader (e.g., some East Asia countries). In this case, the device could display a QR code instead of a URL + pin. The user would simply photograph the QR code using his phone and the approval page would load in the browser. After approving, the user would be directed to continue with the process in the device (typically just press a button/screen to continue).
An additional advantage of this approach is that QR codes can encode relatively longer URLs, so it is possible that one could encode a sufficiently long URL to capture the entire traditional OAuth request. The protocol would be more secure as a result.
If the user does not have access to a mobile device with a QR code reader, there would be an option to use the approach described above.