AI & Agents
Authentication & security
How an MCP client signs in to your academy, what its tokens can do, and the checks the connector runs on every request.
Launching soon: the MCP Connector is not yet available. These pages document the planned first release and may change before launch.
Overview
The connector uses OAuth 2.1. Each academy domain is its own authorization server: the admin signs in on the academy’s login page, and the assistant receives tokens for that academy only. No API key, shared secret, or client credential is involved, and the assistant never sees the admin’s password.
Sign-in flow
Clients that implement the MCP authorization specification discover everything from the connector URL. You don’t need to configure endpoints.
- The client calls the connector URL without a token and gets a
401with aWWW-Authenticatechallenge. The challenge points to the protected-resource metadata (RFC 9728), which names the academy as the authorization server (RFC 8414). - The client identifies itself with a Client ID Metadata Document, an HTTPS URL it controls, or with dynamic client registration (RFC 7591). Redirect URIs must match what the client declared exactly. The only exception is the port on a loopback redirect (RFC 8252).
- The client starts an authorization-code flow with PKCE (S256 only) and names the connector URL as the resource (RFC 8707).
- The admin signs in on the academy, then approves or denies the request on a consent page. The page shows the assistant, the domain that vouches for it (or marks it unverified), the account being connected, and the requested access, area by area. The admin can untick any area before allowing.
- The client exchanges the authorization code for an access token and a refresh token.
Scopes
Scopes are per area of the product, in the form <area>:read or <area>:write, for example users:read and users:write. Every tool belongs to one scope.
- Ceiling per URL. The full-access URL allows every scope. The read-only URL allows only
:readscopes, and a token issued for it stays read-only even if presented to the full-access URL. - Narrowed at consent. The consent page offers only scopes the client requested and the admin’s role can use. The grant records exactly what the admin left ticked. Unknown scopes are dropped, not honored.
- Hidden when not granted. A tool outside the granted scopes isn’t listed, and calling it by name is refused.
- Not enough on its own. A scope never authorizes an action by itself. The admin’s role permissions are checked too.
The MCP Connector page in the admin UI lists what each connection may do. To change a connection’s scopes, disconnect it and connect again.
Tokens
| Credential | Lifetime | Detail |
|---|---|---|
| Authorization code | 60 seconds | Single-use. Bound to the client, redirect URI, PKCE verifier, academy, and connector URL. |
| Access token | 15 minutes | RS256 JWT signed with the academy’s published keys. Its audience is one academy’s connector URL. |
| Refresh token | 30 days idle, 90 days total | Rotates on every use. After either limit, the admin signs in again. |
| Consent request | 30 minutes | Single-use. Tied to the browser that started the sign-in. |
Reusing a spent authorization code or refresh token revokes the sign-in it belongs to. Codes and refresh tokens are stored only as SHA-256 digests. Access tokens aren’t stored.
Access checks
The connector runs these checks on every request, not only at sign-in. Disabling an account, changing its role, or removing its portal access applies to the assistant’s next call.
| Check | Rule |
|---|---|
| Academy | The connector must be enabled for the academy. Otherwise every request is refused with 403, even with a valid token. |
| Domain | A token is honored only on the academy domain it was issued for. A token from another academy, or another service, is refused. |
| Token type | Only connector access tokens are accepted. API keys and session tokens are refused, and no other Thought Industries API accepts a connector token. |
| Connection | The connection behind the token must not have been disconnected. |
| Role | The account’s role must open the admin UI and hold the permission each tool declares, such as user management or course editing. |
| Portals | Portal (panorama) access comes from the signed-in account, never from the request. Site Admins can work across the academy; every other role is limited to the portals it belongs to or administers. |
| Scope | The tool’s scope must be in the grant and within the connector URL’s ceiling. |
Requests are rate-limited per signed-in user, and each tool has its own per-user limit on top. Data-changing and batch tools allow fewer calls. The unauthenticated discovery and sign-in endpoints are rate-limited per IP address.
Disconnecting
- Select Disconnect next to the assistant on the MCP Connector page. Its next request is refused, and it can’t refresh its tokens.
- Removing the connector in the client stops the client using it but doesn’t disconnect it. A client can revoke its refresh token (RFC 7009), but its current access token stays valid until it expires.
- Each admin sees and disconnects their own assistants. Thought Industries super admins can see and disconnect every admin’s.
Security considerations
Signing out doesn’t disconnect assistants. Signing out of the academy or resetting a password leaves connected assistants working. After a suspected compromise, disconnect them on the MCP Connector page.
The assistant receives what the admin can see. The connector sends no data to any AI vendor itself, but tool results go to the connected assistant, and its provider processes them under your agreement with that provider.
Grant only what the assistant needs. Untick areas on the consent page that the assistant won’t use, or connect with the read-only URL. Read tools are flagged read-only to the client; tools that change data aren’t, so clients such as Claude ask before running them. Avoid “always allow” for those tools.