Parameter Name | Description |
---|---|
client_id | Your application’s Client ID. You can find this value in your Application Settings. |
scope | The scopes for which you want to request authorization. These must be separated by a space. You can request any of the standard OIDC scopes about users, such as profile and email , custom claims conforming to a namespaced format, or any scopes supported by the target API (e.g., read:contacts ). Include openid to get an ID Token or to be able to use the /userinfo endpoint to retrieve profile information for the user. Include offline_access to get a Refresh Token (make sure that the Allow Offline Access field is enabled in the API Settings). Note that this must be URL encoded. |
audience | The unique identifier of the API your app wants to access. Use the Identifier value on the Settings tab for the API you created as part of the prerequisites for this tutorial. Note that this must be URL encoded. |
HTTP 200
response with a payload containing device_code
, user_code
, verification_uri
, and expires_in
, interval
, and verification_uri_complete
values:
device_code
is the unique code for the device. When the user goes to the verification_uri
in their browser-based device, this code will be bound to their session.user_code
contains the code that should be input at the verification_uri
to authorize the device.verification_uri
contains the URL the user should visit to authorize the device.verification_uri_complete
contains the complete URL the user should visit to authorize the device. This allows your app to embed the user_code
in the URL, if you so choose.expires_in
indicates the lifetime (in seconds) of the device_code
and user_code
.interval
indicates the interval (in seconds) at which the app should poll the token URL to request a token.user_code
:
Minimum length:
device_code
and user_code
, you must ask the user to go to the verification_uri
on their laptop or smartphone and enter the user_code
:
device_code
is not intended for the user directly and should not be displayed during the interaction to avoid confusing the user.
When building a CLI, you could skip this step and immediately open the browser with verification_uri_complete
.
interval
) from the previous step, you will need to POST
to the token URL sending along the device_code
.
To avoid errors due to network latency, you should start counting each interval after receipt of the last polling request’s response.
Parameter Name | Description |
---|---|
grant_type | Set this to “urn:ietf:params:oauth:grant-type:device_code”. This is an extension grant type (as defined by Section 4.5 of RFC6749). Note that this must be URL encoded. |
device_code | The device_code retrieved in the previous step of this tutorial. |
client_id | Your application’s Client ID. You can find this value in your Application Settings. |
HTTP 4xx
responses:
device_code
has expired. Your application should notify the user that the flow has expired and prompt them to reinitiate the flow.
The expired_token
error will be returned exactly once; after that, invalid_grant
is returned. Your device must stop polling.
HTTP 200
response with a payload containing access_token
, refresh_token
(optionally), id_token
(optionally), token_type
, and expires_in
values:
/userinfo
endpoint or another API. (To learn more about Access Tokens, read Access Tokens.) You will be able to use the Access Token to call /userinfo
only if you included the openid
scope. If you are calling your own API, the first thing your API will need to do is verify the Access Token.
ID Tokens contain user information that must be decoded and extracted. (To learn more about ID Tokens, read ID Tokens.) The id_token
will only be present in the response if you included the openid
scope.
Refresh Tokens are used to obtain a new Access Token or ID Token after the previous one has expired. (To learn more about Refresh Tokens, read Refresh Tokens.) The refresh_token
will only be present in the response if you included the offline_access
scope and enabled Allow Offline Access for your API in the Dashboard.
Refresh tokens must be stored securely since they allow a user to remain authenticated essentially forever.
offline_access
scope when you initiated the authentication request through the authorize endpointPOST
request to the /oauth/token
endpoint in the Authentication API, using grant_type=refresh_token
.
Parameter Name | Description |
---|---|
grant_type | Set this to “refresh_token”. |
client_id | Your application’s Client ID. You can find this value in your Application Settings. |
client_secret | Your application’s Client Secret. You can find this value in your Application Settings. |
refresh_token | The Refresh Token to use. |
scope | (Optional) A space-delimited list of requested scope permissions. If not sent, the original scopes will be used; otherwise you can request a reduced set of scopes. Note that this must be URL encoded. |
HTTP 200
response with a payload containing a new access_token
, id_token
(optionally), token lifetime in seconds (expires_in
), granted scope
values, and token_type
:
context
object’s protocol
property:
Code | Name | Description |
---|---|---|
fdeaz | Failed device authorization request | |
fdeac | Failed device activation | |
fdecc | User canceled the device confirmation | |
fede | Failed Exchange | Device Code for Access Token |
sede | Success Exchange | Device Code for Access Token |