Skip to content
Okibi/ Docs
⌘K
Log inSign up

Guides

Okibi Identity

Let the people who use your CLI sign in with Okibi, while your API keeps checking every request.

Okibi Identity lets the people who use your generated CLI sign in with Okibi. Your API checks each request with the Okibi Partner Kit and still decides what each person may do.

When to use it

Use it when you run the API your CLI calls and can deploy changes to it. Every generated CLI already includes Identity. The Okibi sign-in switch decides whether users are offered it, and it takes effect right away, with no new generation.

Open the project, click Identity in its sidebar, and turn on Okibi sign-in.

Connect your API

  1. On the Identity page, copy the prompt under Give this to your coding agent.
  2. Open your backend repository in your coding agent and paste it. The agent installs @okibi/partner-kit and follows the setup guide inside it.
  3. Deploy your service to a public HTTPS URL.

Then register it. Only workspace owners and admins can do this.

  1. Under Partner registration, enter the Deployed service URL and click Register partner API.
  2. Okibi runs its hosted production checks. If they pass, it registers your API and signs your latest published release.
  3. A dialog shows the new credentials. Click Download env file and move the values into your server's secret manager. Okibi shows the secret only this once.

After you change your deployment, click Run health check under Deployment health, or run okibi identity verify my-cli --url https://api.example.com --hosted.

Lost the secret? Click Rotate partner secret, or run okibi identity partner rotate-secret my-cli --write-env <new-file>. Requests fail until your server has the new value.

How your users sign in

Your users run your generated CLI, not okibi:

Your user's terminal
my-cli auth login
my-cli auth login --email tester@example.com
my-cli auth login --code <code>
my-cli auth status
  • auth login opens the browser. If that can't work, it falls back to a device code.
  • --email sends a one-time approval email instead. The user clicks Approve in the email, or finishes with --code.
  • If the person already signed in to another CLI that uses Okibi Identity on this machine, auth login reuses that sign-in.
  • my-cli auth native switches to your service's own sign-in. my-cli auth native --off switches back.

If your CLI already had its own --email or --code flag, check my-cli auth login --help for the names it uses.

Add Okibi to your own sign-in

The optional Sign in with Okibi card lets your existing auth system recognize the same person who approved the CLI. It is standard OIDC, for Clerk, Supabase, Auth0, Better Auth, Auth.js v4, WorkOS, Amazon Cognito, or Other OIDC. It unlocks once your API is registered. Only workspace owners and admins can set it up.

  1. Pick your Authentication system.
  2. Under Authorized redirect URLs, enter your provider's exact callback URL, one per line, up to five.
  3. Click Create OIDC client and copy the client secret. It is shown once.
  4. Follow the steps under Configure for your provider, then sign in once. The card shows Connection proven when it works.

From the terminal, okibi identity federation init my-cli --redirect-uri https://accounts.example.com/oauth/callback --write-env ./okibi-oidc.env detects your provider and prints its setup steps. See okibi identity for every command.

Next steps

InsightsSee how many people use your CLI with Okibi Identity.MCP serverLet agent clients use your CLI without installing it.