OAuth 2.0 Playground - Device Authorization Grant (2/3)

Request a device code from the authorization server

Start polling authorization server periodically until the code has been successfully entered

Instruct the user where to enter the code

2. Wait for user to enter the user code

We do so by periodically polling authorization server at:

With body data:

Let's break it down...

grant_type=urn:ietf:params:oauth:grant-type:device_code

This is a mandatory parameter that indicates the type of grant being used. In this case we are using the device code.
client_id=

Client ID of the application. This is a public identifier for the client, and it is used by the authorization server to identify the application when redirecting the user back to the client.
device_code=

Device code we have obtained in the previous step.

Start polling

Congratulations, you have just obtained an access token

Let's break down what we have received...

token_type

Indicates the type of token issued. In OAuth 2.0, the common type is "Bearer", which means that whoever bears the token can access the resources.
expires_in

Indicates the number of seconds for which the access_token is valid. After this time, the access_token will expire and a new one must be obtained.
access_token

This is the actual access token, which allows the client application to access the user's protected resources on the resource server (e.g., user profile, photos, etc.).
refresh_token

Used to obtain a new access_token when the current one expires. This allows the client to get a new access_token without requiring the user to log in again.
scope

Specifies the scopes granted by the user to the client application. Scopes determine the permissions associated with the access_token. Here, the granted scopes are email, offline_access, and profile. This means that with the provided access_token, the client application can access the user's email and profile information and is also granted offline access (typically used in conjunction with refresh tokens).

And this concludes the Device Authorization Grant flow. Client application would now be able to request resources on users behalf without having to transfer his credentials with each request.

Try different flow

[ Take me home ]

Device Authorization Grant

2. Wait for user to enter the user code

3. Instruct the user where to enter the code

User code:

Congratulations, you have just obtained an access token

Let's break down what we have received...