Skip to main content
Jinko supports two distinct OAuth flows. Both go through Jinko Auth at auth.gojinko.com.
These tokens are not interchangeable. A token from jinko auth login will fail with unexpected iss claim if you paste it into an MCP client’s Authorization: Bearer header. Use an API key for programmatic MCP access.

​
MCP OAuth (DCR)

Best path for end-user-facing MCP clients. Zero config, the client discovers Jinko’s auth server, registers itself dynamically, and runs OAuth 2.1 + PKCE in the user’s browser.

​
Supported clients

  • Claude Desktop / Claude Web, Settings → Connectors → Add custom connector. Just enter https://mcp.builders.gojinko.com/mcp and leave OAuth fields blank.
  • Claude Code, claude mcp add --transport http jinko https://mcp.builders.gojinko.com/mcp
  • ChatGPT, Add the connector in the desktop or web app’s MCP settings.
  • Cursor, Settings → MCP Servers → Add Server with the endpoint URL.

​
What happens under the hood

1

Discovery

Client GETs https://mcp.builders.gojinko.com/.well-known/oauth-authorization-server to learn the auth server (auth.gojinko.com).
2

Dynamic Client Registration

Client POSTs to the registration endpoint to mint itself a client_id + secret. No human in the loop.
3

Authorization with PKCE

Client opens a browser to auth.gojinko.com, user signs in or signs up. Jinko Auth redirects back with an auth code.
4

Token exchange

Client trades the code for an access token (and refresh token). Stored locally per the client’s conventions.
5

Account auto-provision

On first use, our API pulls the JWT sub claim and provisions a Jinko devplatform user, no waitlist, no manual approval.
Tokens auto-refresh on the client side; you don’t manage anything.

​
CLI OAuth (device flow)

Used when you run jinko auth login and pick the OAuth path (default).
Works over SSH and remote sessions (the URL + code are decoupled from the local browser). Tokens land in ~/.jinko/config.yaml. The SDK and CLI both pick them up. The CLI auto-refreshes tokens before each request when expires_at is near. To clear: jinko auth logout (removes both OAuth tokens and any saved API key from the config).

​
WorkOS OAuth on the REST API

Every /v1 route on api.gojinko.com accepts a WorkOS OAuth access token as a bearer (the same token the CLI device flow mints) alongside jnk_ API keys:
The REST gateway forwards the bearer to the BFF, which verifies it and resolves your user identity. So the two REST auth methods are jnk_ via X-API-Key and WorkOS OAuth via Authorization: Bearer, both of which work on every /v1 route. The SDK and CLI use a token from jinko auth login automatically once you’re logged in.
This is distinct from the MCP endpoint. The “issuer mismatch” caveat above is specific to pasting a CLI token into an MCP client’s Authorization: Bearer header. On the REST /v1 surface the bearer is forwarded and verified by the BFF.

​
Which auth should I use?

When in doubt, an API key is the most portable option.

​
Common failures

See Errors & troubleshooting for HTTP-level debugging.