Latest Content

How to Authorize a Third-Party OAuth Application

Updated on 21 July, 2026

Grant a third-party OAuth application access to your Vultr account within your own permissions and receive a one-time authorization code using the API.

Authorizing a third-party OAuth application grants it permission to act on your Vultr account within a defined set of scopes. When you authorize an application, Vultr issues a one-time authorization code that the application exchanges for an access token, and creates a dedicated role that limits the application to only the permissions you consented to.

Follow this guide to authorize a third-party OAuth application using the Vultr Console and the Vultr API.

Note
  • You can only authorize an application whose requested permissions stay within your own access. If the application requests anything beyond your permissions, the request returns an HTTP 403 Forbidden response and no access is granted.
  • An application that is not Active can be authorized only by users on its draft-mode allowlist. Any other user receives an HTTP 403 Forbidden response.
  • redirect_uri must exactly match a callback URL registered to the application, and response_type must be code. Otherwise the request returns an HTTP 400 Bad Request response.
  • Vultr Console
  • Vultr API

The Vultr consent screen appears when a third-party application redirects you to Vultr to authorize it.

  1. Start the connect or sign-in action from the third-party application. It redirects you to the Vultr consent screen.

  2. Sign in to the Vultr Console if you are prompted.

  3. On the Review and Decide screen, review the application, its developer, and the list of permissions it requests.

  4. Click Authorize to grant access, or Decline Authorization to deny it.

    A confirmation appears, and the browser redirects back to the application, which exchanges the authorization code for an access token. The application then appears in your authorized applications.

  1. Send a POST request to the Authorize OAuth Application endpoint to grant access. Replace CLIENT-ID with the application id, CALLBACK-URL with a callback URL registered to the application, and STATE-VALUE with an opaque string your application generates to protect against cross-site request forgery. The state value is optional but recommended, and Vultr returns it unchanged in the redirect_to URL.

    console 
    $ curl "https://api.vultr.com/v2/oauth/authorize" \
    -X POST \
    -H "Authorization: Bearer ${VULTR_API_KEY}" \
    -H "Content-Type: application/json" \
    -d '{
        "client_id": "CLIENT-ID",
        "redirect_uri": "CALLBACK-URL",
        "response_type": "code",
        "approve": true,
        "state": "STATE-VALUE"
    }'

    A successful request returns an HTTP 200 OK response with a redirect_to URL, a one-time code, the oidc_provider_id, and the token_endpoint. The application uses the code to obtain an access token. The authorization code expires in 10 minutes and can be used only once.

  2. Send a GET request to the List Your Authorizations endpoint to confirm the authorization.

    console 
    $ curl "https://api.vultr.com/v2/oauth/authorizations" \
    -X GET \
    -H "Authorization: Bearer ${VULTR_API_KEY}"

    The response contains an authorizations array. Verify that the application appears with is_revoked set to false.

Re-Authorize an Application After Its Permissions Change

An application owner can change the scope an application requests after you have already authorized it. When you re-authorize the application, Vultr reconciles the change against your existing grant.

Note
Vultr auto-applies scope reductions when you re-authorize, because the application ends up with less access than before. Scope additions return an HTTP 409 Conflict response and require you to re-consent to the new permissions before the application's access continues. The re-checked scope must still stay within your own access, otherwise the request returns an HTTP 403 Forbidden response.

Comments