Authentication
Installing the connector grants no access. Each person signs in separately, and what they can do afterwards is bounded by their own permissions.
What a user signs in to
The first time someone makes a NobleCloak request in Claude, they are sent to NobleCloak to sign in, then returned to their conversation. From then on Claude acts as that person — their calls are attributed to them and governed by their permissions, not by the permissions of whoever installed the connector.
This is why an administrator installing the connector does not hand anyone their own access, and why two people in the same workspace can see different tools.
What they are granting
Two permissions, and deliberately only two:
| Scope | What it allows |
|---|---|
mcp | Call the NobleCloak tools this person is permitted to use |
offline_access | Keep the session alive without re-prompting on every request |
That is the whole set. In particular there are no profile or identity scopes — signing in does not hand Claude a user's name, email, or directory record, because our authorization server does not publish that surface at all. The narrowness is intentional rather than an omission.
offline_access is what stops Claude asking someone to sign in repeatedly
during a working session. A user can end that at any time by revoking the
connector's access.
How the sign-in works
Standard OAuth 2.1 authorization code flow with PKCE, using S256
challenges. The connector is a public client — no client secret is issued,
stored, or pasted anywhere, which is what makes it safe to use from desktop
and mobile clients that cannot keep one.
Claude does not need to be told where to send people. Both discovery documents are published, and a spec-compliant MCP client reads them automatically:
| Document | Where | What it says |
|---|---|---|
| Protected resource metadata (RFC 9728) | /.well-known/oauth-protected-resource on your connector host | Which authorization server governs this connector, and the scopes it accepts |
| Authorization server metadata (RFC 8414) | /.well-known/oauth-authorization-server on that authorization server | The authorization, token, registration, and revocation endpoints, and the supported grants and PKCE methods |
Read the endpoints from those two documents rather than hard-coding them. They are the authoritative source, they are what Claude itself follows, and they stay correct if our internal paths move. Clients that register dynamically can do so at the registration endpoint the second document names.
Sessions and revoking access
Sessions renew silently while someone is working and lapse after a period of inactivity, at which point the next request prompts a fresh sign-in. A lapsed session is normal and is not a fault.
Access can be ended from either side:
- A user removes the connector's access from their own Claude settings.
- An administrator removes the connector from Organization settings → Connectors, which ends it for everyone.
Either way, calls already made remain in the Execution Ledger. That is an audit record, not a cache, and it is retained under our privacy policy.
Related
- Install the connector
- Troubleshooting — including sign-in failures