OAuth 2.0 for TV and limited-input device applications

Page Summary

outlined_flag

• This document describes the OAuth 2.0 protocol designed for limited-input devices, such as TVs and printers, to access the YouTube Data API without the need for traditional browsers or extensive input capabilities.

• Applications must first request a device_code and user_code from the authorization server, then display these codes along with a verification_url to the user who must complete the authentication process on a separate device.

• The application must continuously poll the authorization server using the device_code until the user authorizes the application on another device, at which point the server will respond with the needed access tokens, or send an error if the user denies authorization.

• Once access is granted, the app uses the access_token to make authorized calls to Google APIs, with the option to refresh the token using the refresh_token, and users have the ability to revoke permissions.

• Applications will need to use the correct scopes depending on what is necessary, and there is a list of the supported scopes within the document, with a specific list of youtube scopes, and a list of other non-youtube scopes as well.

This document explains how to implement OAuth 2.0 authorization to access the YouTube Data API using applications running on devices such as TVs, game consoles, and printers. More specifically, this flow is designed for devices that either don't have access to a browser or have limited input capabilities.

OAuth 2.0 allows users to share specific data with an application while keeping their usernames, passwords, and other information private. For example, a TV application could use OAuth 2.0 to obtain permission to select a file stored on Google Drive.

Since the applications that use this flow are distributed to individual devices, it is assumed that the apps cannot keep secrets. They can access Google APIs while the user is present at the app or when the app is running in the background.

Alternatives

If you are writing an app for a platform such as Android, iOS, macOS, Linux, or Windows (including the Universal Windows Platform), that has access to the browser and full input capabilities, use the OAuth 2.0 flow for mobile and desktop applications. (You should use that flow even if your app is a command-line tool without a graphical interface.)

If you only want to sign in users with their Google Accounts and use JWT ID token to obtain basic user profile information, see Sign-In on TVs and Limited Input Devices.

Prerequisites

Enable APIs for your project

Any application that calls Google APIs needs to enable those APIs in the API Console.

To enable an API for your project:

1. Open the API Library in the Google API Console.
2. If prompted, select a project, or create a new one.
3. Use the Library page to find and enable the YouTube Data API. Find any other APIs that your application will use and enable those, too.

Create authorization credentials

Any application that uses OAuth 2.0 to access Google APIs must have authorization credentials that identify the application to Google's OAuth 2.0 server. The following steps explain how to create credentials for your project. Your applications can then use the credentials to access APIs that you have enabled for that project.

1. Go to the Clients page.
2. Click Create Client.
3. Select the TVs and Limited Input devices application type.
4. Name your OAuth 2.0 client and click Create.

Identify access scopes

Scopes enable your application to only request access to the resources that it needs while also enabling users to control the amount of access that they grant to your application. Thus, there may be an inverse relationship between the number of scopes requested and the likelihood of obtaining user consent.

Before you start implementing OAuth 2.0 authorization, we recommend that you identify the scopes that your app will need permission to access.

The YouTube Data API v3 uses the following scopes:

See the Allowed scopes list for installed apps or devices.

Obtain OAuth 2.0 access tokens

Even though your application runs on a device with limited input capabilities, users must have separate access to a device with richer input capabilities to complete this authorization flow. The flow has the following steps:

1. Your application sends a request to Google's authorization server that identifies the scopes that your application will request permission to access.
2. The server responds with several pieces of information used in subsequent steps, such as a device code and a user code.
3. You display information that the user can enter on a separate device to authorize your app.
4. Your application starts polling Google's authorization server to determine whether the user has authorized your app.
5. The user switches to a device with richer input capabilities, launches a web browser, navigates to the URL displayed in step 3 and enters a code that is also displayed in step 3. The user can then grant (or deny) access to your application.
6. The next response to your polling request contains the tokens your app needs to authorize requests on the user's behalf. (If the user refused access to your application, the response does not contain tokens.)

The image illustrates this process:

The following sections explain these steps in detail. Given the range of capabilities and runtime environments that devices may have, the examples shown in this document use the curl command line utility. These examples can be ported to various languages and runtimes.

Step 1: Request device and user codes

In this step, your device sends an HTTP POST request to Google's authorization server, at https://oauth2.googleapis.com/device/code, that identifies your application as well as the access scopes that your application wants to access on the user's behalf. You should retrieve this URL from the Discovery document using the device_authorization_endpoint metadata value. Include the following HTTP request parameters:

Examples

The following snippet shows a sample request:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl

This example shows a curl command to send the same request:

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
     https://oauth2.googleapis.com/device/code

Step 2: Handle the authorization server response

The authorization server will return one of the following responses:

Success response

If the request is valid, your response will be a JSON object containing the following properties:

The following snippet shows a sample response:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

Quota exceeded response

If your device code requests have exceeded the quota associated with your client ID, you will receive a 403 response, containing the following error:

{
  "error_code": "rate_limit_exceeded"
}

In that case, use a backoff strategy to reduce the rate of requests.

Step 3: Display the user code

Display the verification_url and user_code obtained in step 2 to the user. Both values can contain any printable character from the US-ASCII character set. The content that you display to the user should instruct the user to navigate to the verification_url on a separate device and enter the user_code.

Design your user interface (UI) with the following rules in mind:

• user_code
  • The user_code must be displayed in a field that can handle 15 'W' size characters. In other words, if you can display the code WWWWWWWWWWWWWWW correctly, your UI is valid, and we recommend using that string value when testing the way the user_code displays in your UI.
  • The user_code is case-sensitive and shouldn't be modified in any way, such as changing the case or inserting other formatting characters.
• verification_url
  • The space where you display the verification_url must be wide enough to handle a URL string that is 40 characters long.
  • You shouldn't modify the verification_url in any way, except to optionally remove the scheme for display. If you do plan to strip off the scheme (e.g. https://) from the URL for display reasons, be sure your app can handle both http and https variants.

Step 4: Poll Google's authorization server

Since the user will be using a separate device to navigate to the verification_url and grant (or deny) access, the requesting device is not automatically notified when the user responds to the access request. For that reason, the requesting device needs to poll Google's authorization server to determine when the user has responded to the request.

The requesting device should continue sending polling requests until it receives a response indicating that the user has responded to the access request or until the device_code and user_code obtained in step 2 have expired. The interval returned in step 2 specifies the amount of time, in seconds, to wait between requests.

The URL of the endpoint to poll is https://oauth2.googleapis.com/token. The polling request contains the following parameters:

Examples

The following snippet shows a sample request:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

This example shows a curl command to send the same request:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

Step 5: User responds to access request

The following image shows a page similar to what users see when they navigate to the verification_url that you displayed in step 3:

After entering the user_code and, if not already logged-in, logging in to Google, the user sees a consent screen:

Step 6: Handle responses to polling requests

Google's authorization server responds to each polling request with one of the following responses:

Access granted

If the user granted access to the device (by clicking Allow on the consent screen), then the response contains an access token and a refresh token. The tokens enable your device to access Google APIs on the user's behalf. (The scope property in the response determines which APIs the device can access.)

In this case, the API response contains the following fields:

The following snippet shows a sample response:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

Access tokens have a limited lifetime. If your application needs access to an API over a long period of time, it can use the refresh token to obtain a new access token. If your application needs this type of access, then it should store the refresh token for later use.

Access denied

If the user refuses to grant access to the device, then the server response has a 403 HTTP response status code (Forbidden). The response contains the following error:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

Authorization pending

If the user has not yet completed the authorization flow, then the server returns a 428 HTTP response status code (Precondition Required). The response contains the following error:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

Polling too frequently

If the device sends polling requests too frequently, then the server returns a 403 HTTP response status code (Forbidden). The response contains the following error:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

Other errors

The authorization server also returns errors if the polling request is missing any required parameters or has an incorrect parameter value. These requests usually have a 400 (Bad Request) or 401 (Unauthorized) HTTP response status code. Those errors include:

Calling Google APIs

After your application obtains an access token, you can use the token to make calls to a Google API on behalf of a given user account if the scope(s) of access required by the API have been granted. To do this, include the access token in a request to the API by including either an access_token query parameter or an