Introduction
The device authorisation grant is designed for Internet connected devices that either lack a browser to perform a user-agent based authorisation or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorisation flow is impractical. It enables clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorisation to access protected resources by using a user agent on a separate device.
Device-Auth User flow
This section describes how device authorisation flow can be achieved from a device.
API Spec: User Authentication#/Device%20Authorization
Endpoint specifications
Endpoint | HTTP Method | Purpose |
---|---|---|
/api/auth/v1/device | POST | Creates unique user code and a verification URI to present it on a external browser to verify the user. |
/api/auth/v1/device/verify | POST | Verifies the user code with the authenticated user. |
/api/auth/v1/access_token grant_type="urn:ietf:params:oauth:grant-type:device_code" | POST | Provides access_token to the device once the user is verified externally. |
Use Case
1. User Turn on device (e.g: STB) first time
2. User is prompted with a random 8 characters code (aka user_code)
3. User is prompted to go to a website to login (authenticate)
4. Once successfully authenticated, user will be asked to enter the user_code from step 2
5. User enter user_code and submit it
6a. If user_code is valid => the device (in #1) will be successfully login => user can start streaming services entitled to his/her account
6b. If user_code is invalid => the device (in #1) will prompt user that login was failed => user won't be able to use any services
When the user wants to log in, the device starts out by making a POST request to begin the process. The POST request contains only one piece of information, its client_id
. This request is made to a /api/auth/v1/device endpoint that is unique to the Device Flow.
POST https://testing.booxmedia.xyz/api/auth/v1/device client_id={CLIENT_ID}
The server will respond with a JSON document with a few pieces of information.
{ "device_code": "NGU4QWFiNjQ5YmQwNG3YTdmZMEyNzQ3YzQ1YSA", "verification_uri": "https://example.com/device", "user_code": "BDSD-HQMK", "expires_in": 1800, "interval": 5 }
Here’s what the properties in the response mean:
device_code
- This is a long string that the device will use to eventually exchange for an access tokenverification_uri
- This is the URL the user needs to enter into their phone to start logging inuser_code
- This is the text the user will enter at the URL aboveexpires_in
- The number of seconds that this set of values is valid. After this amount of time, thedevice_code
anduser_code
will expire and the device will have to start overinterval
- The number of seconds the device should wait between polling to see if the user has finished logging in
Now the device needs to display the URL and User Code to the user somehow. While the device waits for the user to enter the code and log in, it will make a POST request every 5 seconds as specified by the interval
returned. This POST request will be made to the token endpoint, using a grant type of device_code
.
POST https://authorization-server.com/token
grant_type=urn:ietf:params:oauth:grant-type:device_code
&client_id=CLIENT_ID
&device_code=NGU4QWFiNjQ5YmQwNG3YTdmZMEyNzQ3YzQ1YSA
While the user is busy logging in on their phone, the token endpoint will return the error message below:
{ "error": "authorization_pending" }
The authorization_pending
error means the user isn’t finished logging in, but the code hasn’t yet expired either. The device should try this again after the specified number of seconds. Meanwhile the user will be logging in, choosing a YouTube account, and approving the request.