OAuth Identity Provider

Vultr acts as an OAuth 2.0 identity provider, letting a customer register a third-party application that other Vultr customers can authorize. Once a customer authorizes an application, it receives a signed JSON Web Token (JWT) that it presents to the Vultr API as a Bearer token, scoped to the permissions the customer consented to and never beyond that customer's own access.

This overview describes the actors, resources, and lifecycle of the Vultr OAuth Identity Provider. Use it to understand how the individual guides in this section fit together.

Actors

The OAuth flow involves three actors, and the guides are organized around them.

• Application developer: A Vultr customer who registers and manages an OAuth application. These tasks require an API key that belongs to the root user of the organization.
• End user: A Vultr customer who authorizes a third-party application to act on their account and manages or revokes that access.
• Application runtime: The third-party application code that exchanges authorization codes for access tokens and calls the Vultr API on the end user's behalf.

Resources

The OAuth system is built on a small set of resources.

• OIDC provider: A Vultr-hosted RSA keypair that signs the tokens an application presents to the Vultr API. Each provider has its own issuer identity and discovery document.
• OAuth application: The registered client, identified by a client id and secret, linked to an OIDC provider and a set of callback URLs.
• Scope: An IAM permission policy attached to the application that defines what the application can request.
• Authorization: The record of an end user's consent, which backs the tokens the application holds.
• Access token: The short-lived JWT the application presents to the Vultr API, paired with a refresh token for renewal.

Application Lifecycle

An OAuth application moves through a defined set of states.

• Draft: The application is editable. Only users on its allowlist can authorize it. You attach a scope, set callback URLs, and test the flow in this state.
• PendingReview: The application is submitted and locked against edits while an administrator reviews it.
• Active: The application is approved and available to any Vultr customer. It remains locked against edits.
• Rejected: The application was not approved. Editing any field returns it to Draft.

Token Model

After an end user authorizes an application, the application exchanges a one-time authorization code for an access token at the provider's token endpoint. The authorization code expires in 10 minutes and is single-use, while the access token is a one-hour RS256 JWT. The application renews the token with a rotating refresh token rather than sending the user through consent again. Revoking an authorization tears down the grant and invalidates every token the application holds.