OAuth for connected AI apps

AI apps such as Claude, ChatGPT, Cursor and VS Code connect to Bizisy by signing in, with no key to copy: the person pastes their company's MCP address into the app, signs in to Bizisy, checks what the app may do and presses Allow. This is the MCP authorization flow: OAuth 2.1 with PKCE. Most people never see the details; Connect an AI app has the steps per app.

This page is for developers building an MCP client that connects the same way.

How it works#

1. The client calls the MCP endpoint, https://<company>.bizisy.com/mcp/manage (or /mcp/me), without a token.
2. Bizisy answers 401 with WWW-Authenticate: Bearer resource_metadata="…", pointing to the protected resource metadata (RFC 9728).
3. That document names the company's authorization server: the company address itself. Its metadata (RFC 8414) lists the endpoints.
4. The client identifies itself, by a client ID metadata document (its client_id is an https:// URL) or by dynamic client registration (RFC 7591).
5. The client sends the person to the authorization endpoint with a PKCE challenge. They sign in on the company's own address, see the consent page and press Allow.
6. The client exchanges the code for an access token and a refresh token, then calls the MCP endpoint with Authorization: Bearer <access token>.

Every company is its own authorization server, and a connection works only there: only on that company's MCP endpoints, only for the audience the person allowed, and never on the REST API or the API host.

Endpoints#

All on the company's address, https://<company>.bizisy.com:

Build a client#

• Code flow with PKCE only. response_type=code, code_challenge_method=S256. Other grant types (client credentials, implicit, password) aren't offered.
• Say which server. Send resource=https://<company>.bizisy.com/mcp/manage (or /mcp/me), RFC 8707, or the scope manage or me. Without either, the person chooses on the consent page. Every token response includes a refresh token (offline_access is accepted and changes nothing).
• Register redirect URIs exactly. https:// URLs, loopback http://127.0.0.1 or http://localhost (any port, for desktop and command-line apps), or an app scheme. Fragments and credentials in the URI are refused.
• Client authentication. Public clients send client_id only (token_endpoint_auth_method: none); confidential clients use client_secret_basic or client_secret_post.
• Client ID metadata documents. Bizisy fetches your client_id URL (5-second deadline, public addresses only) and checks that the document names the same client_id. The client_name is what people see on the consent page and in Activity.
• Registered clients that are never used expire after 1 day; a used one is kept until 180 days after its last use.

Tokens#

A refresh token used twice disconnects the connection for safety (two refreshes racing within 10 seconds are refused, not punished). Bizisy stores only hashes of tokens.

A connection also ends when the person disconnects it (Connect AI, or Settings → Connected apps in Manage, where owners and admins see and can disconnect every app), when it hasn't been used for 30 days, and when the person's access is turned off. Connecting to Manage needs a sign-in from the last 12 hours.

What a connected app can do#

A connected app has the person's permissions for the audience they allowed, and the same limits as an API key: it is a machine, so it never sees other people's private or pay data and can't do what stays in the web app (What machines can see). The 300-requests-a-minute rate limit applies per connection. Everything it changes, previews or fails to do shows in Activity with the app's name.

Apps that can't sign in#

Use an API key in the Authorization header instead, on https://api.bizisy.com/mcp/manage or /mcp/me.