Tenant Delegated

Tenant Delegated means your application stays in charge of who your users are. Users log in on your own login page, using the accounts they already have, and LockMCP never sees their password. Your backend hands the hub a short-lived code, the hub trades it for a session, and from then on tool calls run as that user.

It's the most involved of the three identity models — your backend implements a small contract of its own — but it's the only one that keeps the entire login experience inside your product.

When to choose it

What you need to build

Your backend exposes a small set of HTTPS endpoints that LockMCP calls server-to-server, all HMAC-signed:

You'll also need a user directory (any way of authenticating users — email/password, SSO, whatever you already have), publicly reachable HTTPS endpoints, and the HMAC shared key the wizard generates for you.

Setting it up

Connections go through a five-step wizard that's the same for every identity model. Tenant Delegated differs in two places:

Step 3 · Identity setup asks for your Login, Exchange and Validate URLs, generates the HMAC key, and maps your app's role names onto LockMCP roles. Use Test endpoints for a live reachability check before continuing.

Step 4 · Provision doesn't just configure — it runs a seven-check certification suite that actually walks the login → exchange → validate sequence against your live endpoints. All seven must pass before the connection will provision. See Troubleshooting for what each check verifies.

Who assigns roles

A connection's roles have exactly one owner, and the role mapping decides which:

Map each app role to a role on this connection (or to a workspace role with read access only). A login can't hand out a workspace role that carries more than that, such as a role that can manage settings. Step 3 only offers roles a login can assign, and flags any mapping that can't be applied. The connection page keeps flagging it until it's fixed.

Workspace (platform) roles are always assigned by admins. A sign-in through your app never changes them, so someone who manages LockMCP keeps that access however they sign in. Users who only call tools don't need an invitation: their first sign-in through your app creates them. Every role a sign-in removes is recorded in the audit log as Roles replaced by app login.

How a tool call actually authenticates

1. An AI client hits your connection's MCP endpoint with no credentials and gets a 401 plus a pointer to the authorization server.
2. The client starts an OAuth flow; LockMCP redirects the user to your login page.
3. The user signs in on your page. Your app issues a short-lived code and redirects back.
4. LockMCP calls your Exchange endpoint (HMAC-signed) and receives a session token.
5. LockMCP mints its own short-lived ES256 JWT for the client. That's what the AI client presents from then on.
6. On tool calls, LockMCP verifies its JWT and calls your Validate endpoint to confirm the underlying session is still valid and to pick up the user's current roles.

The practical upshot: your backend stays the authority on every request. Revoke a session on your side and the next validate call shuts the AI client out.

Where to go next