---
title: OAuth and scopes
description: How the AI connectors sign in with OAuth 2.0 and PKCE, the 15 scopes the MCP server requires, what each grants, and what OAuth cannot grant.
canonical: https://developers.coevera.com/ai/oauth-and-scopes/
section: ai
publisher: Coevera
---

# OAuth and scopes

**Answer:** The AI connectors sign in with the OAuth 2.0 authorization code flow and PKCE (S256). The user approves 15 scopes: each .full scope grants write and each .read scope grants read on the matching permissions, and settings, Automation Hub and security permissions are never granted. OAuth applications for your own integrations are not yet available; use an API application.

OAuth is how a user lets an assistant act in their Coevera space without giving it a password.
On this site it is documented only as it applies to the MCP server and the AI connectors.

## How sign-in works

1. The client sends the user to Coevera's authorization endpoint with its client ID, a redirect
   URL from the connector's allow-list, the scopes and a PKCE challenge (`S256`).
2. The user signs in to Coevera and picks a space. Only active spaces with an active
   subscription are offered.
3. The consent screen lists the scopes. Coevera accepts the consent only if the user holds the
   **Admin API Access** right in that space and the connector is active for it.
4. The client exchanges the code for an access token at the token endpoint, authenticating with
   its client secret (`client_secret_basic` or `client_secret_post`) and the PKCE verifier.
5. The client calls `POST /mcp` with `Authorization: Bearer` and the token. The server checks the
   token on every request.

The endpoints are published in the MCP server's discovery document:

```text
https://mcp-server.coevera.com/.well-known/oauth-authorization-server
```

| Item                   | Value (discovery document, 2026-10-14)         |
| ---------------------- | ---------------------------------------------- |
| Issuer                 | `https://mcp-server.coevera.com`               |
| Authorization endpoint | `https://crm.coevera.com/oauth2/app/authorize` |
| Token endpoint         | `https://crm.coevera.com/oauth2/app/token`     |
| Grant types            | `authorization_code`                           |
| PKCE methods           | `S256`                                         |
| Client authentication  | `client_secret_basic`, `client_secret_post`    |

Access tokens are valid for one hour. There is no dynamic client registration: the clients are
registered by Coevera, behind the Claude Connector, the ChatGPT Connector and the MCP Connector.

## Scopes

The server requires these 15 scopes. A token that lacks one is answered `403`.

| Scope                      | Access | Covers                                |
| -------------------------- | ------ | ------------------------------------- |
| `accounts.full`            | Write  | Accounts                              |
| `contacts.full`            | Write  | Contacts                              |
| `leads.full`               | Write  | Leads                                 |
| `opportunities.full`       | Write  | Opportunities                         |
| `tasks.full`               | Write  | Tasks                                 |
| `appointments.full`        | Write  | Appointments                          |
| `emails.full`              | Write  | Emails                                |
| `messages.full`            | Write  | Text messages                         |
| `documents.full`           | Write  | Documents (files); needed for uploads |
| `products_and_prices.full` | Write  | Products and price lists              |
| `projects.read`            | Read   | Projects                              |
| `currencies.read`          | Read   | Currencies                            |
| `pipelines.read`           | Read   | Pipelines and their steps             |
| `fields_and_forms.read`    | Read   | Fields and forms                      |
| `units_and_roles.read`     | Read   | Sales units and roles                 |

A `.full` scope becomes **Write**, and a `.read` scope **Read**, on the matching entry of the
application's permissions (the Records, Administration and Misc sections; see
[permissions and scopes](/get-started/permissions-and-scopes/#oauth-scopes)). The **settings**,
**Automation Hub** and **security** permissions can never be granted through OAuth, whatever
the scopes.

The scopes cap what the connector can do; they never extend it. The assistant still sees only
what the signed-in user can see.

## The OAuth application in your space

Approving the consent creates an application of type **OAuth** in the space, listed under
**Administration › Units, Users & Roles › Applications**. Its name and permissions are read-only
there, and it has no **Show Access**, because an OAuth application has no password to show.

## OAuth for your own integration

OAuth applications for third-party integrations are not yet available: there is no way to
register your own OAuth client. Integrations authenticate as an **API application**, with its
user name and password over HTTP Basic: see [authentication](/get-started/authentication/) and
[permissions and scopes](/get-started/permissions-and-scopes/), or start with the
[quickstart](/get-started/quickstart/).