InternetDataInternetData

Device authorization

POST
/oauth/device_authorization

Starts the device flow. Show the user_code to the person and send them to verification_uri; verification_uri_complete has the code already embedded, which is what to open if you can open a browser at all.

Then poll /oauth/token, no faster than interval seconds.

Request Body

application/x-www-form-urlencoded

TypeScript Definitions

Use the request body type in TypeScript.

Response Body

application/json

application/json

application/json

curl -X POST "https://internetdata.io/oauth/device_authorization" \  -H "Content-Type: application/x-www-form-urlencoded" \  -d 'client_id=string'
{
  "device_code": "string",
  "user_code": "string",
  "verification_uri": "string",
  "verification_uri_complete": "string",
  "expires_in": 0,
  "interval": 0
}
{
  "error": "string",
  "error_description": "string"
}
{
  "error": "string",
  "error_description": "string"
}

Discovery GET

RFC 8414 authorization server metadata: the endpoints, the grant types and the scopes this server supports. Read this rather than hardcoding endpoints. It is also served at `/.well-known/openid-configuration`, identically, because several clients probe that path first.

Authorize GET

The browser entry point for the authorization-code flow. This is a redirect target, not something to call from code. An unknown `client_id` or an unregistered `redirect_uri` is shown to the USER and never redirected, because sending an error to an address we have not verified belongs to you is how an open redirector works. Everything else comes back to your `redirect_uri` with `error`, your `state`, and `iss`.