Подробный обзор спецификации авторизации MCP (издание 2025-03-26)

MCP (Model Context Protocol) — это открытый стандарт, который позволяет AI моделям взаимодействовать с внешними инструментами и сервисами. Он широко принят в индустрии. Поскольку MCP поддерживает методы передачи на основе HTTP, удалённый сервер MCP будет играть всё более важную роль в экосистеме MCP.

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

В данной статье будет подробно проанализирована спецификация авторизации MCP. Это поможет вам понять принципы проектирования спецификации авторизации MCP и некоторые направления для реализации авторизации MCP. Поскольку эта спецификация всё ещё развивается, я поделюсь некоторыми мыслями на основе личного опыта в реализации Аутентификатора, включая:

• Преимущества и ограничения OAuth 2.1 как рамок авторизации
• Проблемы двойных ролей сервера MCP как авторизационного и ресурсного сервера
• Практическая сложность реализации полноценного авторизационного сервера
• Анализ подходящих сценариев для делегированной авторизации третьими сторонами
• Практические компромиссы динамической регистрации клиентов
• Важность чёткого определения границ ресурсов сервера MCP

Обзор спецификации авторизации MCP#

Спецификация авторизации MCP определяет процесс аутентификации между сервером MCP (удалённым) и клиентом MCP.

Я считаю, что основа этой спецификации на OAuth 2.1 — это очень разумный выбор. OAuth как рамки протокола авторизации решает проблему, как позволить пользователям авторизовать сторонние приложения на доступ к ресурсам пользователя от их имени. Если вы не знакомы с OAuth, вы можете ознакомиться с AuthWiki-OAuth для получения дополнительной информации.

В сценарии клиента MCP и сервера MCP речь идёт о "пользователях, авторизующих клиента MCP для доступа к ресурсам пользователя на сервере MCP". "Ресурсы пользователя на сервере MCP" в настоящее время в основном относятся к инструментам, предоставляемым сервером MCP, или к ресурсам, предоставляемым серверными службами сервера MCP.

Для реализации процесса аутентификации OAuth 2.1 протокол требует от сервера MCP предоставить следующие интерфейсы для работы с клиентом MCP для завершения процесса аутентификации OAuth 2.1:

• /.well-known/oauth-authorization-server: мета-данные OAuth сервера
• /authorize: точка авторизации, используемая для запросов на авторизацию
• /token: точка токенов, используется для передачи токена и его обновления
• /register: точка регистрации клиента, используется для динамической регистрации клиентов

Процесс аутентификации выглядит следующим образом:

Спецификация также определяет, как сервер MCP поддерживает делегированную авторизацию через сторонние авторизационные серверы.

Пример потока в спецификации выглядит следующим образом (из содержимого спецификации):

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

На мой взгляд, этот сценарий кажется более подходящим для работы с ситуациями, когда сервер MCP является прокси для клиента MCP (пользователя) для доступа к сторонним ресурсам (например, к репозиториям Github), а не когда сервер MCP является прокси для клиента MCP (пользователя) для доступа к собственным ресурсам сервера MCP.

В заключение, согласно протоколу, сервер MCP играет роли как авторизационного сервера, так и ресурсного сервера в OAuth.

Далее давайте обсудим обязанности сервера MCP как авторизационного сервера и ресурсного сервера.

Сервер MCP как служба авторизации#

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

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

Однако реализация функциональности авторизационного сервера на сервере MCP представляет значительную проблему для разработчиков. С одной стороны, большинство разработчиков могут быть не знакомы с концепциями, связанными с OAuth. С другой стороны, существует множество деталей, которые нужно учитывать при реализации авторизационного сервера. Если разработчик не принадлежит к связанному полю, они могут ввести такие проблемы, как проблемы безопасности во время реализации.

Тем не менее, сам протокол не ограничивает сервер MCP в реализации только функциональности авторизационного сервера. Разработчики могут полностью перенаправить или проксировать эти связанные с авторизацией конечные точки к другим авторизационным серверам. Для клиента MCP это ничем не отличается от реализации сервером MCP функциональности авторизационного сервера.

Вы можете задаться вопросом, следует ли подходу использования делегированного стороннего метода авторизации, упомянутого выше?

С точки зрения автора, это в основном зависит от того, являются ли пользователи сторонней авторизационной службы, от которой вы зависите, теми же, что и конечные пользователи сервера MCP. Это означает, что выданный вам сторонний авторизационной службой токен доступа будет напрямую потребляться вашим сервером MCP.

• Если да, тогда вы можете полностью переслать интерфейсы, связанные с авторизацией, в вашем сервере MCP на сторонние авторизационные службы.

• Если нет, то вы должны использовать подход делегированной сторонней авторизации, указанный в спецификации. Вам необходимо поддерживать соотношение между токенами доступа, выданными сервером MCP самим собой, и токенами доступа, выданными сторонними авторизационными службами на сервере MCP.

Я считаю, что подход делегированной сторонней авторизации, указанный в протоколе, несколько неясен в практических приложениях. Протокол, кажется, позволяет сторонним участникам помогать серверу MCP завершить процесс авторизации, но при этом по-прежнему требует, чтобы сервер MCP выдавал свои собственные токены доступа. Это фактически означает, что сервер MCP по-прежнему несет ответственность за выдачу токенов доступа как авторизационный сервер, что не более удобно для разработчиков. Я думаю, что, вероятно, авторы протокола рассматривали то, что прямое возвращение сторонних токенов доступа клиенту MCP может принести некоторые проблемы безопасности (такие как утечка/злоупотребление и т. д.).

Из моего опыта, наиболее подходящий сценарий для делегированной сторонней авторизации, указанной в протоколе, должен быть сценарием "пользователи авторизуют сервер MCP на доступ к сторонним ресурсам". Например, сервер MCP должен получить доступ к репозиторию пользователя на Github и развернуть код репозитория на платформу развертывания кода. В этом случае пользователь должен авторизовать сервер MCP для доступа к своему репозиторию на Github и для доступа к платформе развертывания кода.

В этом сценарии сервер MCP является авторизационным сервером для клиента MCP, поскольку конечные пользователи имеют свою собственную личность на сервере MCP. Сервер MCP является сторонним клиентом для сторонних ресурсов (в данном случае, Github). Ему необходимо получить авторизацию пользователя для доступа к пользовательским ресурсам на Github. Между клиентом MCP и сервером MCP, а также между сервером MCP и сторонними ресурсами идентичности пользователей разделены. Это делает смыслом поддержание отношения между токенами доступа, выданными сервером MCP самим собой, и токенами доступа, выданными сторонними авторизационными службами на сервере MCP.

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

Сервер MCP как ресурсный сервер#

Когда сервер MCP действует как ресурсный сервер, сервер MCP должен проверить, содержит ли запрос клиента MCP действительный токен доступа. Сервер MCP будет решать, позволять ли клиенту MCP доступ к определённым ресурсам на основе области действия токена доступа.

Из определения MCP, ресурс, предоставляемый сервером MCP, должен быть инструментами для использования клиентом MCP. В этом сценарии сервер MCP должен только решать, предоставлять ли пользователям доступ к определённым инструментам.

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

В этом случае, вместо того чтобы говорить, что сервер MCP является ресурсным сервером, предоставляющим инструменты и собственные ресурсы службы, лучше сказать, что существующий ресурсный сервер становится сервером MCP, предоставляющим инструменты для использования клиентом MCP.

Включение ресурсов, предоставляемых собственным ресурсным сервером, в ресурсы, предоставляемые сервером MCP, является в большей степени рассмотрением реальных сценариев. Но я лично предпочитаю, чтобы ресурсы, предоставляемые сервером MCP, имели только инструменты, используемые клиентом MCP, а ресурсы, от которых зависят инструменты, должны быть ресурсами, полученными сервером MCP из других ресурсных серверов (включая первую и третью стороны). Таким образом, все реальные сценарии могут быть охвачены.

Как работает авторизация MCP#

После понимания обязанностей сервера MCP как авторизационного сервера и ресурсного сервера мы можем понять, как именно работает авторизация MCP:

Динамическая регистрация клиентов#

Спецификация также определяет, как авторизационный сервер идентифицирует клиентов. OAuth 2.1 предоставляет протокол динамической регистрации клиентов, позволяющий клиенту MCP автоматически получать ID OAuth клиента без вмешательства пользователя.

Согласно спецификации, сервер MCP должен поддерживать протокол динамической регистрации клиентов OAuth 2.0. Таким образом, клиент MCP может автоматически регистрироваться на новых серверах для получения ID OAuth клиента. Такой подход рекомендован в MCP-сценариях главным образом потому, что:

• Клиент MCP не может узнать все возможные серверы заранее
• Ручная регистрация вызовет неприятности для пользователей
• Это делает подсоединение к новым серверам бесшовным
• Серверы могут реализовать свои собственные политики регистрации

Однако с практической точки зрения у меня есть несколько мыслей на тему применения динамической регистрации клиентов в MCP-сценариях:

• На практике OAuth-сервисов клиент обычно однозначно связан с конкретным приложением. Динамическое создание клиента может не способствовать эффективному управлению связанными ресурсами (пользователями, приложениями и т.д.) в OAuth-сервисах. Поставщики OAuth обычно хотят иметь четкий контроль над подключёнными клиентами, а не позволять любому клиенту регистрироваться как клиент.
• Многие OAuth-сервисы не рекомендуют или не разрешают пользователям динамически создавать клиентов, так как это может привести к злоупотреблению сервисом. Большинство крупных OAuth-провайдеров (таких как GitHub, Google и т.д.) требуют от разработчиков вручную регистрировать клиентов через свою консоль разработчика и могут также потребовать предоставить подробную информацию о приложении, URL-адрес обратного вызова и т.д.
• Ручная регистрация OAuth-клиента на самом деле является одноразовой задачей в процессе разработки, и не обязательно что каждый конечный пользователь должен это делать. Это не повлечет большой нагрузки на разработчиков.
• Для публичных клиентов (таких как нативные приложения, одностраничные приложения и т.д.), у нас есть более безопасные способы реализовать поток OAuth без необходимости динамической регистрации. ID клиента в сочетании с PKCE (Proof Key for Code Exchange) может предоставить достаточно безопасный поток OAuth для публичных клиентов без динамического создания клиентов.
• Хотя протокол указывает, что использование динамической регистрации клиентов может избежать необходимости клиентам узнавать ID клиента заранее, на самом деле клиент MCP всегда должен знать адрес удалённого сервера MCP заранее. Если это так, указание ID клиента при передаче адреса удалённого сервера MCP не создаст много дополнительных проблем. Или, мы можем также создать соглашение для клиента MCP, чтобы он запрашивал у сервера MCP ID клиента, что не является сложной задачей.

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

Итог#

Эта статья глубоко анализирует философию дизайна и проблемы реализации спецификации авторизации MCP. Как рамка авторизации на основе OAuth 2.1, эта спецификация стремится решить ключевую проблему, как удалённый сервер MCP получает доступ к ресурсам пользователя от имени пользователей.

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

Стоит отметить, что спецификация авторизации MCP всё ещё развивается. Как члены команды Logto, мы будем продолжать следить за последними разработками этой спецификации и систематически оптимизировать наши решения для безопасного взаимодействия между AI-моделями и внешними сервисами.