Resource audience и токены

L26 · MCP 2026-07-28 · открытая бета · редакция 2026.10-beta1

Один токен не должен открывать все API вокруг. Я привязываю MCP access token к ресурсу, для которого его выдали. Это защищает от использования токена другого сервиса на моём MCP endpoint.

Предварительно: L25

Как я это использую

Resource Indicators по RFC 8707 связывают запрос авторизации и обмен кода с целевым resource. MCP server проверяет issuer, audience, срок, подпись или introspection согласно своему типу токена, а затем scopes и объектные права. Не предполагайте, что любой access token — JWT; opaque token требует своего механизма проверки.

Разбираем конкретный контракт

Это учебный fixture: поля с доменом .example и идентификаторы вымышлены. Если показан фрагмент, его нужно поместить в соответствующий envelope выбранного профиля.

{
  "authorization_request": {
    "resource": "https://tasks.example/mcp"
  },
  "token_request": {
    "resource": "https://tasks.example/mcp"
  },
  "validation": [
    "issuer",
    "audience",
    "expiry",
    "scope",
    "object permissions"
  ],
  "forward_to_tracker": false
}

Что легко сломать

Token passthrough во внешний сервис запрещённая архитектурная подмена. Если MCP server обращается в трекер, у этого вызова отдельные credentials и делегирование. В упражнении проверьте два токена с одинаковым scope, но разными audience: совпадение scope не спасает чужой audience.

Практика и самопроверка

Назначить resource и проверить применимость токена. Инъекция токена другого сервиса не открывает защищённую операцию.

Я советую сначала предсказать результат, затем изменить один параметр в лаборатории и объяснить разницу. Сохраните небольшой fixture с нормальным и ошибочным случаем для своего проекта. Тренажёр открыт без регистрации; для сохранения ответов на тесты и завершения урока войдите в аккаунт.

В конце страницы — три вопроса. После правильных ответов можно завершить урок; ошибка в следующей тренировке не стирает уже полученное подтверждение этой редакции теста.

На что я опирался

• authorization: первичный источник
• auth-security: первичный источник

Профиль и ссылки проверены 15 октября 2026. Core, deprecated compatibility и extensions в этом курсе помечены отдельно. Примеры объясняют выбранные сценарии; для реализации сверяйте нормативные MUST/SHOULD и schema соответствующей версии.