Авторизация в MCP

Авторизация в MCP - часть спецификации Model Context Protocol, которая определяет, как MCP-клиент получает токен доступа к защищённому MCP-серверу и передаёт его в каждом HTTP-запросе. Она построена на OAuth 2.1 и наборе связанных стандартов IETF. MCP-сервер выступает сервером ресурсов OAuth, а токены выдаёт отдельный сервер авторизации.

Авторизация впервые появилась в спецификации 2025-03-26 и с тех пор менялась в каждой редакции. В статье описана текущая версия спецификации, 2026-07-28, и отмечено, что менялось в предыдущих. Базовые понятия протокола (хост, клиент, сервер, транспорты) описаны в статье Что такое MCP.

Кратко

Какую задачу решает

Удалённый MCP-сервер часто обслуживает многих пользователей, и ему нужно знать, кто отправил запрос и что этот пользователь разрешил. Токен в файле конфигурации выпускают вручную для каждого сервера и хранят в предсказуемом месте на диске.

MCP-клиенты универсальны: хост может подключиться к серверу, с которым у него нет предварительных отношений. OAuth 2.0 (RFC 6749) исходит из обратного: клиент регистрируется до начала процедуры и узнаёт адреса эндпоинтов из документации сервиса.

Спецификация решает это цепочкой стандартных документов. На запрос без токена сервер отвечает HTTP 401 со ссылкой на свои метаданные, в которых назван сервер авторизации. Клиент представляется адресом собственного документа метаданных, поэтому предварительная регистрация не нужна. Полученный токен привязан к одному MCP-серверу.

История

В таблице - как менялась авторизация от версии к версии спецификации.

Роли

Спецификация определяет трёх участников и агент пользователя:

• Сервер ресурсов (resource server) - защищённый MCP-сервер. Он принимает запросы с токенами доступа, проверяет их и отвечает.
• Клиент OAuth - MCP-клиент. Он выполняет запросы от имени владельца ресурса, обычно пользователя хоста.
• Сервер авторизации (authorization server) при необходимости взаимодействует с пользователем и выдаёт токены доступа для MCP-сервера. Он может размещаться вместе с MCP-сервером или отдельно; его реализацию спецификация не определяет.
• Агент пользователя (user agent) - браузер, в котором пользователь входит в систему и даёт согласие.

Когда применяется авторизация

Авторизация необязательна. Если реализация её поддерживает, требования зависят от транспорта:

• реализации на транспорте на основе HTTP следует соблюдать спецификацию авторизации;
• реализации на stdio не следует её соблюдать, она берёт учётные данные из окружения, например из переменных окружения, которые задал хост;
• реализация на другом транспорте обязана соблюдать принятые для него практики безопасности.

Сами транспорты описаны в статье Транспорты MCP.

Полная процедура

Схема показывает процедуру от первого запроса без токена до первого запроса с токеном. Идентификатор клиента получен одним из способов регистрации, описанных ниже.

Browser              MCP client                   MCP server              Authorization server
   |                      |                            |                            |
   |                      |-- request without token -->|                            |
   |                      |<- 401, WWW-Authenticate ---|                            |
   |                      |-- GET resource metadata -->|                            |
   |                      |<- authorization_servers ---|                            |
   |                      |-- GET authorization server metadata ------------------->|
   |                      |<- endpoints, PKCE, iss support -------------------------|
   |                      |   record issuer, PKCE      |                            |
   |<- authorization URL -|                            |                            |
   |-- code_challenge, resource, scope -------------------------------------------->|
   |                      |                            |                            | user signs in, consents
   |<- redirect: code, state, iss --------------------------------------------------|
   |-- code, state, iss ->|                            |                            |
   |                      |   compare iss with issuer  |                            |
   |                      |-- token request, code_verifier ------------------------>|
   |                      |<- access token, refresh token --------------------------|
   |                      |-- request + Bearer token ->|                            |
   |                      |<- MCP response ------------|                            |

Обнаружение

Метаданные защищённого ресурса

MCP-сервер обязан реализовать OAuth 2.0 Protected Resource Metadata (RFC 9728). Его документ метаданных обязан содержать поле authorization_servers хотя бы с одним сервером авторизации. Сервер делает документ доступным одним из двух способов: передаёт адрес в параметре resource_metadata заголовка WWW-Authenticate ответа 401 или размещает документ по well-known URI.

Ответ на запрос без токена может выглядеть так:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp", scope="files:read"

Если в заголовке нет resource_metadata, клиент строит well-known URI и проверяет их по порядку. Для эндпоинта https://example.com/public/mcp первый из них - https://example.com/.well-known/oauth-protected-resource/public/mcp: путь вставляется после well-known префикса. Второй - корневой: https://example.com/.well-known/oauth-protected-resource. Клиенты обязаны поддерживать оба способа обнаружения.

Документ метаданных сервера из примера выше:

{
  "resource": "https://mcp.example.com/mcp",
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["files:read", "files:write"],
  "bearer_methods_supported": ["header"],
  "resource_name": "Example MCP Server"
}

По RFC 9728 значение resource обязано совпадать с адресом, по которому клиент обратился к серверу; иначе клиент не должен использовать документ.

Метаданные сервера авторизации

Сервер авторизации обязан поддерживать хотя бы один из двух способов обнаружения: OAuth 2.0 Authorization Server Metadata (RFC 8414) или OpenID Connect Discovery 1.0. Клиенты обязаны поддерживать оба и проверять несколько well-known адресов в установленном порядке.

Значение issuer в полученном документе обязано совпадать с идентификатором издателя, из которого построен адрес. Документ с хоста злоумышленника, где указан другой издатель, отклоняется.

Сокращённый пример метаданных сервера авторизации с полями, важными для MCP:

{
  "issuer": "https://auth.example.com",
  "authorization_endpoint": "https://auth.example.com/authorize",
  "token_endpoint": "https://auth.example.com/token",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"],
  "scopes_supported": ["files:read", "files:write", "offline_access"],
  "client_id_metadata_document_supported": true,
  "authorization_response_iss_parameter_supported": true
}

Регистрация клиента

До начала авторизации клиент обязан получить идентификатор клиента (client ID). Спецификация определяет три способа. Клиенту, который поддерживает их все, следует применять их в таком порядке:

1. данные предварительной регистрации для этого сервера, если они у клиента есть;
2. Client ID Metadata Document, если сервер авторизации объявляет client_id_metadata_document_supported;
3. Dynamic Client Registration, если сервер авторизации публикует registration_endpoint;
4. запрос данных клиента у пользователя.

Client ID Metadata Documents

При Client ID Metadata Documents идентификатор клиента - HTTPS-адрес, который ведёт на JSON-документ с метаданными клиента. Адрес обязан использовать схему https и содержать путь. Документ обязан содержать как минимум client_id, client_name и redirect_uris, а client_id обязан в точности совпадать с адресом документа.

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "redirect_uris": ["http://127.0.0.1:3000/callback"],
  "grant_types": ["authorization_code", "refresh_token"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Получив идентификатор клиента в виде адреса, сервер авторизации загружает документ, проверяет client_id и адрес перенаправления из запроса и кеширует документ по заголовкам HTTP-кеширования. Способ основан на черновике IETF.

Предварительная регистрация

Клиентам следует поддерживать статические учётные данные клиента: идентификатор, встроенный в клиент для конкретного сервера авторизации, или форму, в которую пользователь вводит идентификатор клиента, зарегистрированный им самим.

Dynamic Client Registration

Динамическая регистрация клиентов (Dynamic Client Registration, RFC 7591) позволяет клиенту получить идентификатор запросом к registration_endpoint сервера авторизации, без участия пользователя. С 2026-07-28 она устарела и сохранена для совместимости с серверами авторизации, которые не поддерживают Client ID Metadata Documents. Клиент, который её использует, обязан указать application_type: native для настольных, CLI- и локальных веб-приложений, web для удалённых веб-приложений.

Привязка учётных данных к серверу авторизации

Учётные данные предварительной регистрации и данные, сохранённые после Dynamic Client Registration, принадлежат выдавшему их серверу авторизации. Клиент обязан хранить их с ключом issuer этого сервера. Если метаданные защищённого ресурса начинают указывать другой сервер авторизации, клиент не должен повторно использовать старые учётные данные и обязан зарегистрироваться заново. Идентификаторы на основе Client ID Metadata Documents переносимы: сервер авторизации разрешает адрес по запросу, поэтому при смене сервера новая регистрация не нужна.

Запрос авторизации и токен

PKCE

PKCE (Proof Key for Code Exchange, RFC 7636) защищает код авторизации от перехвата. Перед запросом клиент создаёт случайный code_verifier и передаёт в запросе авторизации его хеш SHA-256 - code_challenge. В запросе токена клиент передаёт сам code_verifier, поэтому обменять код может только клиент, который начал процедуру.

MCP-клиенты обязаны реализовать PKCE и использовать метод S256, если это технически возможно. OAuth не определяет, как узнать о поддержке PKCE, поэтому клиент проверяет code_challenge_methods_supported в метаданных сервера авторизации. Если поля нет, клиент обязан прекратить процедуру. Сервер авторизации с OpenID Connect Discovery обязан включать это поле для совместимости с MCP.

Указатели ресурса

Указатель ресурса (resource indicator, RFC 8707) - параметр resource, который называет сервер, для которого запрашивается токен. MCP-клиенты обязаны передавать его и в запросе авторизации, и в запросе токена, даже если сервер авторизации его не поддерживает. Значение - канонический URI MCP-сервера: абсолютный URI со схемой и без фрагмента, например https://mcp.example.com/mcp или https://mcp.example.com. Рекомендуется форма без завершающей косой черты.

Запрос авторизации со всеми обязательными параметрами:

GET /authorize?response_type=code&client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json&redirect_uri=http%3A%2F%2F127.0.0.1%3A3000%2Fcallback&scope=files%3Aread&state=af0ifjsldkj&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256&resource=https%3A%2F%2Fmcp.example.com%2Fmcp HTTP/1.1
Host: auth.example.com

Проверка издателя

При атаке mix-up вредоносный сервер авторизации пытается заставить клиента передать ему код или токен, выданный другим, честным сервером (RFC 9207). PKCE от этого не защищает: клиент отправил бы свой code_verifier на эндпоинт токенов злоумышленника.

Перед открытием браузера клиент обязан записать issuer из проверенных метаданных вместе с верификатором PKCE и state. Серверам авторизации следует добавлять параметр iss в ответы авторизации и объявлять это полем authorization_response_iss_parameter_supported. Клиент проверяет ответ до того, как отправит код на какой-либо эндпоинт токенов:

Сравнение - простое строковое, без какой-либо нормализации. Оно распространяется и на ответы с ошибкой: при несовпадении клиент не показывает error, error_description и error_uri.

Перенаправление, которое проходит проверку, и следующий за ним запрос токена:

HTTP/1.1 302 Found
Location: http://127.0.0.1:3000/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=af0ifjsldkj&iss=https%3A%2F%2Fauth.example.com

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=http%3A%2F%2F127.0.0.1%3A3000%2Fcallback&client_id=https%3A%2F%2Fapp.example.com%2Foauth%2Fclient-metadata.json&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk&resource=https%3A%2F%2Fmcp.example.com%2Fmcp

Использование токена доступа

Клиент передаёт токен в заголовке Authorization со схемой Bearer. Заголовок обязан быть в каждом HTTP-запросе к серверу, а не только в первом. Передавать токен в строке запроса URI нельзя. С версии 2026-07-28 нет и сессии протокола: каждый запрос несёт собственную авторизацию.

Запрос вызова инструмента с токеном:

POST /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: read_file

{"jsonrpc": "2.0", "id": 7, "method": "tools/call", "params": {"name": "read_file", "arguments": {"path": "report.md"}, "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28", "io.modelcontextprotocol/clientCapabilities": {}}}}

Сервер проверяет токен так, как требует OAuth 2.1, и убеждается, что токен выдан для него как для аудитории (audience). На недействительный или просроченный токен сервер отвечает HTTP 401. Сервер не должен принимать и передавать дальше токены, выданные для других ресурсов. Клиент не должен отправлять серверу токены, выданные другими серверами авторизации.

Когда MCP-сервер вызывает другой API, он выступает отдельным клиентом OAuth этого API с отдельным токеном. Пересылка токена клиента (передача токена дальше, token passthrough) запрещена.

Ошибки и права

Коды ответа

В таблице - коды HTTP, которые сервер возвращает при ошибках авторизации.

Выбор прав

Право (scope) - именованное разрешение, которое несёт токен, например files:read. Серверу следует указывать в заголовке WWW-Authenticate ответа 401 параметр scope с правами, нужными для ресурса. При первой авторизации клиент берёт права из этого параметра. Если параметра нет, клиент запрашивает все права из scopes_supported в метаданных защищённого ресурса или не передаёт scope, если нет и этого поля.

Права из запроса сервера клиент считает определяющими для текущей операции, как бы они ни соотносились со scopes_supported. scopes_supported должно содержать минимальный набор для базовой работы. Серверам не следует указывать там и в запросах прав offline_access: токены обновления не являются требованием ресурса.

Дозапрос прав

Дозапрос прав (step-up authorization) - запрос нового токена с расширенными правами, когда текущего токена для операции недостаточно. Получив такой токен, серверу следует ответить HTTP 403 с error="insufficient_scope", нужными правами и resource_metadata:

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope", scope="files:write", resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource/mcp", error_description="File write permission required for this operation"

Клиент вычисляет объединение прав, запрошенных ранее, и прав из ответа, заново проходит авторизацию и повторяет исходный запрос. Объединение сохраняет права, которые нужны другим операциям. Серверу следует называть все права, нужные операции, в одном ответе. Клиентам следует ограничивать число повторов; клиенты, действующие от своего имени (client_credentials), могут вместо этого прервать запрос. Серверы обязаны учитывать иерархию прав, в которой более широкое право включает более узкое.

Токены обновления

Токен обновления (refresh token) позволяет клиенту получить новый токен доступа без участия пользователя. Клиент, которому нужны токены обновления, обязан хранить их в тайне, ему следует указать refresh_token в grant_types своих метаданных, и он может запросить offline_access, если сервер авторизации его перечисляет. Клиент не должен рассчитывать, что токен обновления будет выдан.

Серверам авторизации следует выдавать короткоживущие токены доступа, а для публичных клиентов они обязаны обновлять токен обновления при каждом использовании.

Требования безопасности

Security Considerations спецификации охватывают такие атаки:

• кража токенов: токены хранятся защищённо;
• защита передачи: эндпоинты сервера авторизации работают по HTTPS, адреса перенаправления - localhost или HTTPS;
• открытое перенаправление: адреса перенаправления регистрируются и сравниваются точно, клиент проверяет state;
• атаки mix-up: клиент проверяет iss;
• confused deputy: MCP-прокси-сервер получает согласие пользователя для каждого клиента;
• риски Client ID Metadata Documents: подделка запросов при загрузке документов, подмена адресов перенаправления на localhost.

Эти и другие риски описаны в статье Безопасность MCP, проверки авторизации сервера - в статье Тестирование MCP-серверов.

Расширения авторизации

Случаи без интерактивного согласия пользователя покрывают два официальных расширения. OAuth Client Credentials определяет доступ между системами. Enterprise-Managed Authorization (io.modelcontextprotocol/enterprise-managed-authorization) позволяет организации управлять доступом к MCP-серверам через свой провайдер идентификации, и сотрудникам не нужно авторизовывать каждый сервер отдельно. Расширения описаны в статье Расширения MCP.

Авторизация MCP и смежные механизмы

С учётными данными в MCP и рядом с ним работают несколько механизмов. В таблице - чем они различаются.

Авторизация MCP защищает сам MCP-сервер. Если серверу нужен доступ к стороннему сервису от имени пользователя, он получает его отдельно, через elicitation в режиме URL: сервер направляет пользователя по адресу, и учётные данные не проходят через клиент. Использовать elicitation в режиме URL для авторизации пользователей на самом сервере нельзя.

Две процедуры не делят токены. Запросы elicitation передаются через многоэтапные запросы (Multi Round-Trip Requests), которые описаны в статье MCP без состояния.

Термины

Источники

• Authorization, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Authorization Server Discovery, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Client Registration, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Authorization Security Considerations, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Key Changes, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Authorization, спецификация 2025-03-26(откроется в новой вкладке) (на английском)
• Key Changes, спецификация 2025-06-18(откроется в новой вкладке) (на английском)
• Key Changes, спецификация 2025-11-25(откроется в новой вкладке) (на английском)
• Enterprise-Managed Authorization(откроется в новой вкладке) (на английском)
• The OAuth 2.1 Authorization Framework, draft-ietf-oauth-v2-1-13(откроется в новой вкладке) (на английском)
• RFC 6749: The OAuth 2.0 Authorization Framework(откроется в новой вкладке) (на английском)
• RFC 9728: OAuth 2.0 Protected Resource Metadata(откроется в новой вкладке) (на английском)
• RFC 8414: OAuth 2.0 Authorization Server Metadata(откроется в новой вкладке) (на английском)
• RFC 8707: Resource Indicators for OAuth 2.0(откроется в новой вкладке) (на английском)
• RFC 9207: OAuth 2.0 Authorization Server Issuer Identification(откроется в новой вкладке) (на английском)
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients(откроется в новой вкладке) (на английском)
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol(откроется в новой вкладке) (на английском)
• OAuth Client ID Metadata Document, draft-ietf-oauth-client-id-metadata-document-00(откроется в новой вкладке) (на английском)