---
title: "Connect your identity provider"
description: "Configure generated products for Clerk, Better Auth, WorkOS, Auth0, or your own authentication."
url: https://typeship.dev/docs/integrations/authentication-providers
markdown: https://typeship.dev/docs/integrations/authentication-providers.md
section: "Authentication"
---
> ## Documentation index
> Fetch the documentation index at https://typeship.dev/llms.txt or every prose page and both generated references at https://typeship.dev/llms-full.txt.
> Append .md to any prose docs URL, or send Accept: text/markdown, for the markdown twin of that page.
> Select existing code examples with Accept-Code-Language: typescript, python, or go (one value), or add ?codeLanguage=python to a Markdown URL. The query parameter takes precedence. Unsupported values return the full docs with a notice.

# Connect your identity provider

Configure generated products for Clerk, Better Auth, WorkOS, Auth0, or your own authentication.

Keep the account system your customers already use. Register your generated product with that provider, then configure Typeship to obtain credentials your API accepts.

The examples below are public `auth` configuration fragments. Create the OAuth application with your provider first, then copy its public settings into Typeship and add the API identity settings from [Add browser login](https://typeship.dev/docs/guides/browser-login).

## Provider requirements

Browser sign-in requires a public OAuth application that supports Authorization Code with PKCE and a loopback callback. Device login additionally requires a standard device-authorization endpoint. A backend SDK using client credentials needs a separate confidential application; its secret stays in that application's runtime.

A remote MCP server has a separate trust boundary. Its authorization server must issue a token whose audience identifies the MCP endpoint and whose scopes permit the connection. That connection token is never reused as an API credential. See [remote MCP authentication](https://typeship.dev/docs/targets/mcp#streamable-http).

## Clerk

Create a **public OAuth application**, keep consent enabled, and register the CLI's loopback callback. Use your Clerk Frontend API URL as the exact issuer. Add your API's scopes to the application and request `offline_access` for a refresh token. See [Clerk's OAuth configuration](https://clerk.com/docs/guides/configure/auth-strategies/oauth/how-clerk-implements-oauth).

```json
{
  "auth": {
    "oauth_server": {
      "issuer": "https://your-instance.clerk.accounts.dev",
      "scopes": ["openid", "api:read", "offline_access"]
    },
    "oauth_applications": {
      "cli": {
        "client_id": "YOUR_PUBLIC_CLIENT_ID",
        "redirect_uri": "http://127.0.0.1:43821/callback"
      }
    },
    "oauth_application": "cli"
  }
}
```

Your API must explicitly [accept and verify OAuth access tokens](https://clerk.com/docs/guides/configure/auth-strategies/oauth/verify-oauth-tokens), then enforce the requested API permissions. A browser session and an OAuth API grant are different credentials.

For SDKs, your application supplies the OAuth access token through the generated client's [credential callback](https://typeship.dev/docs/targets/sdk#authentication). TypeScript, Python, and Go resolve that callback for each request attempt, so your application can supply a renewed token without rebuilding the client. Your application owns token acquisition and renewal; the SDK does not read a saved CLI login.

For organizations, enable Organizations and add `user:org:read` to the allowed and requested scopes. Clerk's consent page lets the user choose an organization. Verify the token and its consent-bound organization, check current membership, and return that organization from your API identity read. See [organization setup](https://typeship.dev/docs/projects/config#let-customers-choose-an-organization).

Clerk [device authorization](https://clerk.com/docs/guides/configure/auth-strategies/oauth/device-authorization-grant) requires provider enablement and a device grant on the client. Check the actual tenant metadata before selecting it. A working browser client does not establish device availability.

For remote MCP, the connection token must identify your MCP endpoint as its audience. Typeship supports both [signed JWTs and server-side introspection](https://typeship.dev/docs/targets/mcp#opaque-access-tokens), but introspection cannot supply a missing audience. If your Clerk application cannot issue a resource-bound MCP token, use a separate authorization server for the MCP connection. Keep that grant separate from the credential used to call your API.

## Better Auth

Use the actual OAuth Provider plugin with JWT support, a public native client, and your API registered as an allowed resource. Permit the resource for that client as well. Configure your existing sign-in and consent pages; those pages stay in your application. See [Better Auth's OAuth Provider](https://better-auth.com/docs/plugins/oauth-provider).

```json
{
  "auth": {
    "oauth_server": {
      "issuer": "https://auth.example.com/api/auth",
      "scopes": ["openid", "api:read", "offline_access"],
      "resource": "https://api.example.com"
    },
    "oauth_applications": {
      "cli": {
        "client_id": "YOUR_PUBLIC_CLIENT_ID",
        "redirect_uri": "http://127.0.0.1:43821/callback"
      }
    },
    "oauth_application": "cli"
  }
}
```

Keep the issuer path. Set `oauth_server.discovery_url` if your deployment publishes metadata elsewhere. Your API must verify the signature, issuer, resource audience, and permissions on its access token.

For device login, add OAuth Device Authorization to the OAuth Provider, enable the device grant on the public client, and use its OAuth token endpoint. The standalone device plugin's first-party session token is a different integration. See [Better Auth device authorization](https://better-auth.com/docs/plugins/device-authorization).

For organization accounts, use the organization plugin and an OAuth post-login page. Select a membership, bind consent to it, and include the organization in API access-token claims. Verify current membership when authorizing API requests. The generated CLI checks the organization returned by your API and retains that identity through refresh.

## WorkOS

For a distributed CLI, create a **public WorkOS Connect OAuth application** and register its callback. Public applications use PKCE. Configure the exact issuer from your AuthKit domain's metadata and the scopes your API requires. See [Connect OAuth applications](https://workos.com/docs/authkit/connect/oauth).

```json
{
  "auth": {
    "oauth_server": {
      "issuer": "https://YOUR_AUTHKIT_DOMAIN",
      "scopes": ["openid", "profile", "offline_access"]
    },
    "oauth_applications": {
      "cli": {
        "client_id": "YOUR_CONNECT_CLIENT_ID",
        "redirect_uri": "http://127.0.0.1:43821/callback"
      }
    },
    "oauth_application": "cli"
  }
}
```

Add your API's required scopes to this fragment. Connect selects an organization during authorization and includes `org_id` in the access token. Your API must validate the token, its intended audience, and organization access; expose the result through your identity read.

AuthKit CLI Auth and WorkOS Connect use different endpoints and token contracts. Use browser PKCE for this setup. Enable device login only when the selected authorization server advertises a standard device grant and token response; an endpoint override cannot add provider support.

## Auth0

Register a **Native application** for Authorization Code with PKCE and no client secret. Register your callback, define your API, and use its API identifier as the audience. Configure the API permissions you need. See [Auth0's native PKCE flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce).

```json
{
  "auth": {
    "oauth_server": {
      "issuer": "https://YOUR_TENANT.auth0.com/",
      "scopes": ["openid", "read:items", "offline_access"],
      "audience": "YOUR_API_IDENTIFIER"
    },
    "oauth_applications": {
      "cli": {
        "client_id": "YOUR_NATIVE_CLIENT_ID",
        "redirect_uri": "http://127.0.0.1:43821/callback"
      }
    },
    "oauth_application": "cli"
  }
}
```

Use the exact issuer advertised by your tenant. Enable offline access and configure refresh-token policy before requesting `offline_access`. Your API validates the resulting access token and permissions, including organization context when applicable.

Typeship's `--organization` flag verifies the API response. To request a particular Auth0 organization, set `organization_parameter: "organization"` on the selected OAuth application and map the same stable provider organization ID in your API identity read, then use `--login-organization`.

## Your own authentication backend

If your provider implements public-client OAuth, configure its exact issuer, client, scopes, and API identity like the examples above.

If your application signs customers in and issues API keys instead, implement the [custom browser approval contract](https://typeship.dev/docs/guides/browser-login#use-your-own-browser-approval-flow): start a request, obtain explicit browser approval, exchange proof for a credential once, and support revocation.

```json
{
  "auth": {
    "approval_url": "https://api.example.com/cli-auth"
  }
}
```

For example, your customer signs in to your dashboard, selects an organization they belong to, and approves read access. Your backend issues a dedicated API credential with that scope. The CLI receives it only after proving it initiated the request, then verifies the account through your API before saving it when identity mapping is configured.

Your backend owns approval, account selection, credential issuance, expiry, and revocation. Deploy this service with the application that owns credential storage and authorization. Package helpers can live in a reviewed [linked Draft with checks](https://typeship.dev/docs/guides/customize); they do not replace application-owned account linking or access policy. Local MCP can reuse the compatible saved CLI profile; SDKs and remote MCP use their own application-owned credential integrations.

## Sitemap

[Documentation index](https://typeship.dev/llms.txt)