# OpenWork Provider Authentication Methods: OAuth, API Key, and None Explained

> Discover OpenWork provider authentication methods including OAuth 2.0 and API key. Learn how to secure your connections with detailed explanations.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: deep-dive
- Published: 2026-08-09

---

**OpenWork supports three provider authentication methods: OAuth 2.0, API key, and none, defined in the `authType` enum of the MCP connection action schema.**

The `different-ai/openwork` repository implements a flexible authentication system for connecting external AI model providers (LLM providers) to organizations. Understanding these provider authentication methods is essential for configuring secure connections to services like OpenAI, Anthropic, or public demo endpoints.

## The Three Provider Authentication Methods in OpenWork

OpenWork's platform encodes authentication strategies in the **`authType`** field of the Model-Connection-Provider (MCP) connection action schema. These methods accommodate different security requirements and provider capabilities.

### OAuth 2.0 Authentication

The **OAuth** method implements the standard OAuth 2.0 authorization flow. When connecting a provider via OAuth, users are redirected to the provider's consent page to authorize access. The system exchanges the authorization code for an access token, which is then stored according to the configured credential mode.

This method is defined in [`packages/types/src/den/mcp-connection-action.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/mcp-connection-action.ts) where `authType` accepts `"oauth"` as a valid enum value. OAuth is ideal for production environments where user-specific access control and token rotation are required.

### API Key Authentication

The **API key** method utilizes a static secret key or credential that the provider accepts for all API calls. Unlike OAuth, this approach uses a persistent credential that does not require user redirection or token refresh flows.

In the schema, this corresponds to `authType: "apikey"`. Organizations can configure whether the key is stored as a **shared** credential (accessible organization-wide) or as a **per-member** credential (individual user access).

### No Authentication (Public Endpoints)

The **none** authentication method indicates that no credentials are required for the connection. This configuration applies to providers exposing public endpoints or testing scenarios where credential management is unnecessary.

Specified as `authType: "none"` in the connection schema, this method streamlines setup for open-access models or internal development environments.

## How Authentication Methods Work in the Connection Flow

OpenWork orchestrates provider connections through a structured flow involving connection actions, credential modes, and state management.

### Connection Action Schema

Every authentication attempt begins with a `connection_action` payload that specifies the desired `authType`. The `openworkCloudMcpConnectionActionSchema` in [`packages/types/src/den/mcp-connection-action.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/mcp-connection-action.ts) validates these requests, ensuring the `authType` field contains one of the three supported values: `"oauth"`, `"apikey"`, or `"none"`.

### Credential Mode Configuration

The **credential mode** determines token storage scope:

- **Shared**: Credentials are stored centrally and accessible to all organization members
- **Per-member**: Each user stores their own tokens, isolating access between users

### Connection State Machine

The system maintains connection states that drive UI prompts:

- `needs_connection`: Initial state requiring authentication input
- `reauth_required`: Existing credentials expired or revoked
- `provider_error`: Authentication failure requiring troubleshooting

The **Provider Auth Modal** ([`apps/app/src/react-app/domains/connections/provider-auth/provider-auth-modal.tsx`](https://github.com/different-ai/openwork/blob/main/apps/app/src/react-app/domains/connections/provider-auth/provider-auth-modal.tsx)) presents these states to users and guides them through the appropriate authentication flow based on the selected `authType`.

## Implementing Provider Authentication in Code

Developers interact with these authentication methods by posting connection action payloads to the Den API endpoint `POST /v1/llm-providers/:providerId/connections`.

### OAuth Connection Example

```json
{
  "version": 1,
  "kind": "connection_action",
  "source": "openwork-cloud",
  "connectionId": "conn-123",
  "connectionName": "OpenAI",
  "authType": "oauth",
  "credentialMode": "per_member",
  "state": "needs_connection",
  "actor": "member",
  "action": {
    "type": "connect",
    "surface": "openwork_your_connections",
    "retry": "search_capabilities"
  }
}

```

### API Key Connection Example

```json
{
  "version": 1,
  "kind": "connection_action",
  "source": "openwork-cloud",
  "connectionId": "conn-456",
  "connectionName": "Anthropic",
  "authType": "apikey",
  "credentialMode": "shared",
  "state": "needs_connection",
  "actor": "member",
  "action": {
    "type": "update_credentials",
    "surface": "openwork_your_connections",
    "retry": "search_capabilities"
  }
}

```

### No Authentication Connection Example

```json
{
  "version": 1,
  "kind": "connection_action",
  "source": "openwork-cloud",
  "connectionId": "conn-789",
  "connectionName": "PublicDemo",
  "authType": "none",
  "credentialMode": "shared",
  "state": "needs_connection",
  "actor": "member",
  "action": {
    "type": "connect",
    "surface": "openwork_your_connections",
    "retry": "search_capabilities"
  }
}

```

## Key Source Files and Implementation Details

Understanding the provider authentication methods requires examining specific files across the OpenWork codebase:

- **[`packages/types/src/den/mcp-connection-action.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/mcp-connection-action.ts)**: Defines the `authType` Zod enum (`oauth`, `apikey`, `none`) and the `openworkCloudMcpConnectionActionSchema` that validates all connection requests.

- **[`apps/app/src/react-app/domains/connections/provider-auth/provider-auth-modal.tsx`](https://github.com/different-ai/openwork/blob/main/apps/app/src/react-app/domains/connections/provider-auth/provider-auth-modal.tsx)**: The React component that renders authentication options in the UI, handling OAuth redirects and API key input forms.

- **`ee/apps/den-api/src/routes/v1/llm-providers/[id]/connections.ts`**: Server-side route handler that processes connection creation and updates, interpreting the `authType` field to trigger appropriate credential storage logic.

- **[`docs/external-mcp-oauth.md`](https://github.com/different-ai/openwork/blob/main/docs/external-mcp-oauth.md)**: Documentation detailing the OAuth integration process for external MCP providers.

## Summary

- OpenWork defines three provider authentication methods in the MCP connection schema: **OAuth 2.0**, **API key**, and **none**.
- The `authType` enum in [`packages/types/src/den/mcp-connection-action.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/mcp-connection-action.ts) strictly types these options as `"oauth"`, `"apikey"`, and `"none"`.
- **Credential modes** (`shared` vs `per_member`) control whether tokens are stored organization-wide or per individual user.
- The **Provider Auth Modal** component dynamically renders authentication flows based on the selected method and connection state.
- Connection actions are processed through the Den API endpoint `POST /v1/llm-providers/:providerId/connections` according to the `openworkCloudMcpConnectionActionSchema`.

## Frequently Asked Questions

### What provider authentication methods does OpenWork support for LLM providers?

OpenWork supports three distinct authentication methods defined in the `authType` field: **OAuth 2.0** for standard authorization flows, **API key** for static credential authentication, and **none** for public endpoints requiring no credentials. These options are encoded in the Zod schema at [`packages/types/src/den/mcp-connection-action.ts`](https://github.com/different-ai/openwork/blob/main/packages/types/src/den/mcp-connection-action.ts) and cover all supported provider connection scenarios.

### How does OAuth 2.0 work in OpenWork provider connections?

When using OAuth 2.0 authentication, OpenWork redirects users to the provider's consent screen to authorize access. The system exchanges the resulting authorization code for an access token, which is then stored according to the credential mode (either shared across the organization or specific to the individual member). This flow is managed by the Provider Auth Modal and tracked through connection states like `needs_connection` and `reauth_required`.

### Can I use OpenWork with providers that don't require authentication?

Yes, OpenWork supports providers without authentication requirements through the `authType: "none"` configuration. This method is useful for public demo endpoints or testing environments. When selected, the connection flow bypasses credential collection and proceeds directly to capability discovery, though it still maintains the standard connection action structure for consistency.

### Where are provider credentials stored in OpenWork?

Provider credential storage depends on the **credential mode** specified in the connection action. **Shared** credentials are stored centrally and accessible to all organization members, while **per-member** credentials are isolated to individual user accounts. The server-side handler in `ee/apps/den-api/src/routes/v1/llm-providers/[id]/connections.ts` manages this storage logic based on the `authType` and `credentialMode` fields.