Provider Management & Auth
Relevant source files
The following files were used as context for generating this wiki page:
- apps/app/src/react-app/domains/connections/provider-auth/store.ts
- ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-editor-screen.tsx/dashboard/_components/llm-provider-editor-screen.tsx)
- ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-detail-screen.tsx/dashboard/_components/llm-provider-detail-screen.tsx)
- ee/apps/den-web/app/(den)/dashboard/_components/sso-screen.tsx/dashboard/_components/sso-screen.tsx)
- apps/app/src/react-app/domains/cloud/org-onboarding-page.tsx
- ee/apps/den-api/src/app.ts
Provider Management and Authentication in OpenWork is a multi-layered system designed to handle LLM provider configurations, organizational access controls, and secure credential storage. It supports three primary authentication methods: OAuth, direct API keys, and Cloud-managed imports. This system ensures that users can connect to over 50 LLMs while maintaining enterprise-grade security through SSO and organizational policies.
The architecture bridges local desktop configurations with remote cloud services, allowing for "Local-first, cloud-ready" workflows. Organizations can manage a catalog of providers, curate specific models for their teams, and enforce desktop app restrictions through a centralized control plane.
Provider Authentication Methods
OpenWork supports diverse authentication flows to accommodate different provider requirements and security postures.
Authentication Types
| Method | Description | Target Use Case |
|---|---|---|
| OAuth | Interactive browser-based authorization. | Providers like OpenAI (browser-based) or custom OAuth MCPs. |
| API Key | Manual entry of sensitive credentials (e.g., sk-...). | Direct local connections or specific catalog providers. |
| Cloud | Managed by the organization; credentials shared via Den API. | Enterprise teams using shared organizational keys. |
Sources: apps/app/src/react-app/domains/connections/provider-auth/store.ts:40-48, ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-editor-screen.tsx:288-300
OAuth Flow Logic
The OAuth flow involves starting an authorization request, redirecting the user to the provider, and handling the callback to complete the connection.
The sequence ensures that the desktop app correctly captures the authorization state and updates the local opencode.jsonc configuration.
Sources: apps/app/src/react-app/domains/connections/provider-auth/store.ts:742-835
Organizational Management (Den API)
The den-api serves as the control plane for organizational providers. Admins can configure providers from a global catalog or define custom providers using JSON schemas.
Provider Catalog vs. Custom Providers
- Catalog Providers: Pre-configured templates (e.g., Anthropic, OpenAI) with defined NPM packages, API bases, and required environment variables.
- Custom Providers: Manual JSON configurations allowing organizations to define their own model endpoints and logic.
Sources: ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-editor-screen.tsx:20-30, 310-400
Access Control & Visibility
Providers within an organization are governed by access rules involving:
- Teams: Group-based access to specific LLM credentials.
- Members: Individual grants for specific users.
- Roles: Admins and Owners can manage SSO and provider details, while Members consume them.
The relationship model allows granular control over which groups can use expensive or sensitive LLM resources.
Sources: ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-detail-screen.tsx:200-265, ee/apps/den-web/app/(den)/dashboard/_components/llm-provider-editor-screen.tsx:550-650
SSO & Domain Verification
For enterprise security, OpenWork supports SAML and OIDC protocols through the Den dashboard.
SSO Configuration Parameters
| Parameter | Type | Protocol | Description |
|---|---|---|---|
Issuer URL | String | SAML/OIDC | The unique identifier for the Identity Provider. |
Entry Point | String | SAML | The URL where SAML requests are sent. |
Client ID | String | OIDC | The public identifier for the OIDC client. |
Domain | String | Both | The email domain associated with the SSO (e.g., company.com). |
Sources: ee/apps/den-web/app/(den)/dashboard/_components/sso-screen.tsx:160-230
Domain Verification Process
To prevent unauthorized domain hijacking, organizations must verify their domains using DNS TXT records.
Verified domains ensure that SSO login flows are restricted to the legitimate owners of the corporate domain.
Sources: ee/apps/den-web/app/(den)/dashboard/_components/sso-screen.tsx:120-155, 330-360
Cloud Provider Sync
The desktop app maintains a synchronization loop with the Den Cloud API to import and update organizational providers locally.
Sync Logic
The ProviderAuthStore performs a "sweep" of orphaned providers and reconciles local opencode.jsonc with remote organization state.
- Sign-in/Launch: Triggers a full reconciliation.
- Import: Cloud-managed providers are injected into the local config with comments identifying them as managed.
- Cleanup: On sign-out, managed provider entries are removed to prevent credential leakage.
// Example of Cloud Import comment injection
const cloudProviderComment = (provider: Pick<DenOrgLlmProvider, "id" | "name">) =>
`// OpenWork Cloud import: ${provider.name
.replace(/\s+/g, " ")
.trim()} (${provider.id}). Manage this entry from Cloud settings.`;
Sources: apps/app/src/react-app/domains/connections/provider-auth/store.ts:460-465, 1070-1150
Conclusion
The Provider Management & Auth system provides a secure bridge between the OpenWork desktop application and enterprise LLM resources. By integrating local configuration management with a cloud-based organizational control plane (Den), OpenWork enables seamless sharing of curated AI models and tools while enforcing strict security policies via SSO and domain verification.