Discovery
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.
Response Body
application/json
curl -X GET "https://internetdata.io/.well-known/oauth-authorization-server"{
"issuer": "string",
"authorization_endpoint": "string",
"token_endpoint": "string",
"device_authorization_endpoint": "string",
"revocation_endpoint": "string",
"scopes_supported": [
"string"
],
"response_types_supported": [
"string"
],
"grant_types_supported": [
"string"
],
"code_challenge_methods_supported": [
"string"
],
"token_endpoint_auth_methods_supported": [
"string"
],
"authorization_response_iss_parameter_supported": true,
"service_documentation": "string"
}Reveal POST
Returns an existing key's secret. Its own scope rather than part of `apikeys.manage`, because the two are different acts: rotating replaces a secret you never see, while this hands one over. Refused with `NOT_RETRIEVABLE` for a key issued before this product stored secrets recoverably - that secret was never kept, so no retry will ever produce it. Rotate the key instead.
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.