> For the complete documentation index, see [llms.txt](https://docs.nerovasystems.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nerovasystems.com/mcp-server/authentication.md). # Authentication and consent The MCP server accepts two credentials, both resolving to the same organization-scoped machine identity: 1. **OAuth sign-in** (recommended) — the client signs you in with your Nerova account and you approve a scoped, revocable connection. 2. **API key bearer** — an organization API key sent as a bearer token, for clients without OAuth support. Either way, every tool call is authorized server-side with the connection's permissions and fails closed when a scope, tenant grant, or entitlement is missing. ## OAuth sign-in Nerova is a standard OAuth 2.1 authorization server. Clients discover it automatically: an unauthenticated request to the MCP endpoint returns a challenge pointing at the protected-resource metadata (`https://api.nerovasystems.com/.well-known/oauth-protected-resource`), which names `https://app.nerovasystems.com` as the authorization server with metadata at `/.well-known/oauth-authorization-server`. The flow is fully automatic in MCP clients that support OAuth: * **Dynamic client registration** (RFC 7591) at `/oauth/register` — public clients only; no client secret is issued. * **Authorization** at `/oauth/authorize` with PKCE (S256 required). You sign in with your normal console account; organization owners and admins can approve connections. * **Consent** — the consent screen shows who is asking, and you choose the permission areas the connection may use. Connections use **Live**, the only supported environment, and require an active production entitlement, which your free testing allowance provides. * **Token exchange** at `/oauth/token` — short-lived access tokens (about ten minutes) with rotating refresh tokens. Every refresh re-validates the grant and your organization's entitlement, so revoked access dies within the access-token lifetime. ## Permissions and tool visibility The permission areas on the consent screen are the same scopes API keys use — see [Scopes](https://docs.nerovasystems.com/documentation/getting-started/authentication#scopes). The connection's grant filters `tools/list`: tools whose scopes were not granted are not shown. Granting a scope never bypasses tenant authorization; the connection sees exactly the tenants granted to it. ## Live only A connection is bound to **Live** at consent, exactly like an API key's `nrv_live_` prefix. There is one connection URL, and tool calls act on real tenants your credential is granted. Only Live credentials exist. If the free testing allowance runs out before a commercial agreement is signed or a card is saved, calls stop until one of them is in place; see [Platform access](https://docs.nerovasystems.com/documentation/console/platform-access#from-approval-to-your-first-invoice). ## API key bearer Clients that cannot run an OAuth flow send an organization API key as a plain bearer token: ```http Authorization: ****** ``` `` is a placeholder. The key's scopes and tenant grants apply unchanged; only Live keys (`nrv_live_`) exist. Create and manage keys in the console — see [Manage API keys](https://docs.nerovasystems.com/documentation/console/api-keys). ## Revocation Revoke a connection at any time in the console under **Developers → Connections**. Revocation stops refresh immediately and the current access token expires within minutes. API keys are revoked from the [API keys page](https://docs.nerovasystems.com/documentation/console/api-keys) as usual. Both paths are audit-logged. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.nerovasystems.com/mcp-server/authentication.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.