OAuth authorization server
Posit Connect includes an OAuth 2.1 authorization server that allows third-party applications to authenticate users and access Connect on their behalf. This enables AI tools, development environments, and other OAuth-compliant clients to connect to content and APIs on Connect.
This documentation covers Connect’s OAuth authorization server for third-party client authentication. For other OAuth features in Connect, see:
- OAuth integrations for accessing external services (Google, Databricks, Snowflake, etc.)
- OpenID Connect authentication for user single sign-on
Overview
The OAuth authorization server implements:
- OAuth 2.0 Dynamic Client Registration (RFC 7591) for automatic client setup
- OAuth 2.1 Authorization Code flow with Proof Key for Code Exchange (PKCE) for secure authentication
- OAuth 2.0 Authorization Server Metadata (RFC 8414) for client discovery
When a user authorizes a client, the client receives an access token that grants the same permissions the user has on Connect. The client can then make API calls and access content on the user’s behalf.
This provides an alternative to API keys. While API keys require users to manually generate and configure credentials, OAuth allows applications to request access through a browser-based authorization flow. OAuth tokens are short-lived and automatically refresh.
OAuth endpoints
Connect exposes the following OAuth endpoints:
| Endpoint | Description |
|---|---|
/.well-known/oauth-authorization-server |
Server metadata (RFC 8414) |
/oauth/v1/register |
Dynamic client registration (RFC 7591) |
/oauth/v1/authorize |
Authorization endpoint |
/oauth/v1/token |
Token endpoint |
OAuth clients use these endpoints automatically during the authentication flow.
Example: MCP clients
One example of OAuth client authentication is enabling AI applications to use MCP servers deployed on Connect. Applications that support the Model Context Protocol (MCP) include:
- Claude Code, Codex, and other terminal interfaces
- Copilot, Positron Assistant, Cursor, and other IDE-based tools
- Other MCP-compatible AI assistants
When users connect their application to an MCP server on Connect, the OAuth flow handles authentication automatically. Users authorize the connection once in their browser, and the application can then access the MCP server’s tools and resources.
For information about deploying MCP servers to Connect, see the MCP servers user guide.
Configuration
Enabling OAuth clients
The OAuth authorization server is enabled by default. To disable it, set:
[Server]
OAuthClientsEnabled = falseSee Server.OAuthClientsEnabled in the configuration reference.
Allowed redirect URIs
OAuth clients use Dynamic Client Registration (DCR) to register with Connect automatically. During registration, clients specify a redirect URI where users are sent after authorizing the connection. This registration happens automatically and is invisible to the end user.
Connect allows the following redirect URIs by default:
http://localhostandhttp://127.0.0.1(any port) for tools running on your machinehttps://vscode.dev/redirectandhttps://insiders.vscode.dev/redirectfor VS Codecursor://anysphere.cursor-mcp/oauth/callbackfor Cursor
To allow additional redirect URIs, such as for Posit Workbench or custom applications, use the OAuthAllowedRedirectURI setting. You can specify multiple URIs:
[Server]
OAuthAllowedRedirectURI = https://workbench.example.com/
OAuthAllowedRedirectURI = https://myapp.example.com/callbackSee Server.OAuthAllowedRedirectURI in the configuration reference.
Security considerations
Server-wide access
When a user authorizes an OAuth client, the client gains access to all Connect content and APIs that the user can access. Clients are not limited to certain content items. To manage users’ access to MCP servers and other content via the OAuth flow, use the same access-control mechanisms used more generally in Connect.
Redirect URI validation
Connect validates redirect URIs to prevent authorization code interception attacks. Connect only accepts URIs matching the allowed list (localhost, the default URIs, and any URIs you configure) during client registration.
Be cautious when adding redirect URIs. Only add URIs for applications you trust, as they will be able to obtain access tokens for any user who authorizes them.
Token security
Access tokens issued by the OAuth server:
- Are short-lived and automatically refresh
- Cannot be used to obtain the user’s password or other credentials