Choosing an Identity Model
Every connection picks one of three ways to recognise your users. This page is the decision aid — if you just want the one-line summary of each, Getting Started has it.
The short version: if you're unsure, start with Identity Brokering. It needs nothing from you, works with every AI client, and the decision isn't permanent.
Decide in two questions
Q1 — Do your users need to sign in with accounts they already have?
- No, new accounts are fine → Identity Brokering. Stop here.
- Yes → continue.
Q2 — Will people connect from Claude Desktop, ChatGPT or Cursor?
- Yes → Tenant Delegated. It's the only model that reuses your existing accounts and supports those clients.
- No, integration is programmatic → Token Exchange if you run an OIDC identity provider; Tenant Delegated if you don't.
Full comparison
| Identity Brokering | Token Exchange | Tenant Delegated | |
|---|---|---|---|
| Who authenticates users | LockMCP | Your identity provider | Your app's login page |
| Setup effort | None | Two URLs | Build endpoints + login page |
| You host auth infrastructure | No | You already do | Yes |
| Users keep existing accounts | No | Yes | Yes |
| Desktop AI clients (Claude Desktop, ChatGPT, Cursor) | Yes | No | Yes |
| Your backend called on each tool call | No | No | Yes — validate endpoint |
| Custom-branded login | No | Your IdP's | Fully yours |
| Time to first working connection | Minutes | Under an hour | Days |
The trade-offs that actually matter
Desktop AI client support
Token Exchange connections cannot be used from Claude Desktop, ChatGPT connectors or Cursor. Those clients complete an interactive browser login, which Token Exchange deliberately disables — the whole point is that your IdP handles sign-in programmatically. Token Exchange connections integrate programmatically instead — see Programmatic Integration.
If desktop clients matter, that rules Token Exchange out on its own, regardless of what identity provider you run.
Who's on the hook when something breaks
- Identity Brokering — sign-in is entirely LockMCP's responsibility.
- Token Exchange — your IdP must stay reachable for new sign-ins. Existing sessions keep working through a brief IdP outage, because tokens are verified against LockMCP's issuer, not yours.
- Tenant Delegated — your validate endpoint is called on tool calls. If it's slow or down, tool calls fail. It's also the only model where you own an availability and latency budget (validate must respond within 5 seconds).
Revocation speed
- Tenant Delegated gives the tightest control: revoke a session on your side and the next validate call shuts the client out.
- Identity Brokering and Token Exchange rely on token expiry. Removing a member stops future sign-ins, but an already-issued token stays valid until it expires.
If instant per-session revocation is a hard requirement, that points to Tenant Delegated.
Effort, honestly
Tenant Delegated is meaningfully more work than the other two. You implement a login page and several server-to-server endpoints, all HMAC-signed, and they have to pass a seven-check certification suite before the connection provisions. That's a real project, not an afternoon.
Choose it because you need the control — not because it sounds the most thorough.
Common situations
| Your situation | Suggested model |
|---|---|
| Evaluating LockMCP, want a demo working today | Identity Brokering |
| Internal tool, small team, no existing IdP | Identity Brokering |
| Company already on Okta / Entra ID / Auth0, integrating programmatically | Token Exchange |
| Company on an IdP, but users need Claude Desktop | Tenant Delegated |
| SaaS product exposing customer data, login must be your branded page | Tenant Delegated |
| Your backend must authorise every individual call | Tenant Delegated |
Changing your mind later
Identity model is set per connection, which makes this low-stakes in two ways.
Run different models side by side. Nothing stops you having a Tenant Delegated connection for customer-facing use and an Identity Brokering one for your internal team. Each gets its own MCP endpoint and its own tools.
Or switch a connection's model. Change it in Step 1 and re-run provisioning. What that costs:
| Switch | What it means |
|---|---|
| To Identity Brokering | Users need LockMCP accounts — invite them under Members & Access before they can connect. |
| To Token Exchange | Your users must exist in the registered IdP. Desktop AI clients stop working. |
| To Tenant Delegated | You need the endpoints and login page built first; the connection won't provision until they pass certification. |
In all cases connected AI clients must re-authenticate, since the way they obtain a token changes. Your tools, roles and specs are unaffected — those belong to the connection, not the identity model.
Where to go next
- Identity Brokering — no setup required
- Token Exchange — bring your own identity provider
- Tenant Delegated — own the whole login experience
- Create a Connection — the wizard, once you've chosen