OAuth apps
Last validated:
OAuth apps let internal tools act on a tailnet on behalf of individual users through a standard OAuth 2.0 authorization code flow (RFC 6749 section 4.1). A user completes a Tailscale-hosted consent screen, and the resulting authorization carries that user's identity. Access control rules, audit log entries, and quotas apply to the user who granted consent, not to a shared service identity.
Each OAuth authorization flow follows the same pattern, so the topics below share a common structure. An Owner or Admin creates an OAuth app through the Tailscale API, and a developer implements the authorization code flow in their tool.
OAuth apps and OAuth clients are different mechanisms. OAuth clients use the client credentials flow to create tag-owned resources tied to a service identity. OAuth apps use the authorization code flow to act on behalf of an individual user. For an overview of all OAuth-related documentation, refer to the OAuth hub.
Requirements
Before you create an OAuth app, confirm you meet the following requirements.
- Owner or Admin role in the tailnet.
- An API access token with admin scope for creating OAuth apps through the API.
- The OAuth app and every user who authorizes through it must belong to the same tailnet. This flow does not support users from other tailnets.
- For developers implementing the flow: working knowledge of OAuth 2.0 authorization code grants and the ability to handle HTTP redirects and token exchanges.
Guides
The following guides cover specific tasks you can perform with OAuth apps.
Device provisioning with OAuth apps
Build internal tools that provision tailnet devices on behalf of individual users with a standard OAuth authorization code flow, so each device carries the consenting user's identity.
Limitations
- Authorization is restricted to a single tailnet. Only users in the same tailnet as the OAuth app can authorize through it.
- The Tailscale-hosted consent screen cannot be customized.