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.
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.
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.
{
"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, 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. 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.
Clerk device authorization 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, 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.
{
"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.
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.
{
"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.
{
"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: start a request, obtain explicit browser approval, exchange proof for a credential once, and support revocation.
{
"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; 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.