Authorize
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.
Query Parameters
"code"S256 only. plain is refused rather than downgraded.
"S256"Returned unchanged. Use it to bind the response to your request.
RFC 8707. What the token is FOR, so it cannot be replayed elsewhere.
Response Body
curl -X GET "https://internetdata.io/oauth/authorize?client_id=string&redirect_uri=string&response_type=code&code_challenge=string"Device authorization POST
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.
Token POST
Three grant types. `urn:ietf:params:oauth:grant-type:device_code` polls a device authorization. Until the person approves it answers `authorization_pending`; poll faster than `interval` and it answers `slow_down`, which means widen your interval and keep it widened. `authorization_code` exchanges a code from `/oauth/authorize`, with the `code_verifier` matching the challenge you sent. `refresh_token` exchanges a refresh token. The presented token is consumed whatever happens next, so store the new one before using it.