Device authorization - PingOne - PingOne Cloud Platform

This grant type is typically used to access a protected resource through a device that lacks a browser or has limited user input capabilities, such as a smart TV or appliance.

The device authorization grant process takes place between the user, device, PingOne authorization server, and the Resource Server (RS). For more information about the grant type, see the OAuth 2.0 Device Authorization Grant specification.

1. The device sends a device authorization request to PingOne, the authorization server at its device authorization endpoint.
2. PingOne returns a device authorization response. Among other parameters, the response contains a device code, a user code, and a verification URI.
3. The device provides the verification URI in a query parameter and instructions to the user, as in the following example:

   Using a browser on another device, visit:
   https://www.example.com
   Enter the code:
   HVF7-B4KW
   

4. The device starts sending token requests to PingOne to poll whether the user has completed the authorization process.
   Important:

   The token request must include the device authorization grant type, urn:ietf:params:oauth:grant-type:device_code, the device code, and the user code.

   For each token request it receives, PingOne returns a response. The payload varies depending on the authorization status.

5. The user completes the authorization process by:
   1. Going to the verification URI on a second device that has a browser, such as a smartphone or a computer.
   2. Fulfilling the authentication requirements.
   3. Entering the user code or confirming a prepopulated user code.
   4. Approving or denying the scope of permissions requested by the device.
6. The device continues polling PingOne for an authorization status.
7. PingOne validates the user code and provides the device with an access token (and an ID token if applicable) in the token response.

   If the user denies the scope of permissions, PingOne provides the device with a relevant error message in the token response.

8. The device provides the access token to the resource server to access protected resources.
9. The resource server validates the access token.
10. The resource server provides the requested data to the device.