Паттерны аутентификации для APS MCP-серверов: две границы вместо одной
Саммари
Автор разбирает рекомендуемые паттерны аутентификации для кастомных MCP-серверов поверх Autodesk Platform Services: у такого сервера всегда две независимые авторизационные границы — между MCP-клиентом и сервером и между сервером и APS — и смешение этих двух уровней называют самой частой ошибкой. Материал опирается на ревизию MCP-спецификации 2026-07-28 (remote-серверы теперь ожидаются как OAuth 2.1 resource servers с Client ID Metadata Documents) и завершается репозиторием aps-mcp-auth-examples, реализующим каждую комбинацию паттернов рабочим кодом.
Из этого следует, что проектирование любого Revit/APS MCP-сервера начинается с двух вопросов «как сервер аутентифицируется у APS?» и «как клиент — у сервера?», а не с выбора транспорта: таблица 4×3 сразу даёт допустимую комбинацию под сценарий.
На практике для Revit-инструментов агентной автоматизации выбор короткий: локальный STDIO-инструмент над личными файлами — PKCE с отложенным входом, серверная автоматизация против общих проектов — SSA, чтобы не зависеть от наличия человека за пайплайном.
Важный нюанс: запрет token passthrough — это не стиль, а защита от confused deputy; если ваш сервер прокидывает bearer-токен клиента в APS, два слоя схлопываются и любой принесённый токен получает полномочия сервера.
Ограничение: паттерны описаны для экосистемы Autodesk и апеллируют к конкретным APS-режимам (2LO/SSA/3LO/PKCE); сама двухграничная рамка переносима, но таблица решений требует адаптации под другой API-провайдер.