Расширьте возможности вашего бизнеса: Подключите AI-инструменты к вашему существующему сервису с контролем доступа
Узнайте, как расширить возможности вашего бизнеса, безопасно подключая AI-инструменты к вашим существующим сервисам с использованием Персональных Токенов Доступа и Протокола Контекста Модели (MCP), с полным исходным кодом и практическими примерами.
YijunDeveloper
Хватит тратить недели на аутентификацию пользователей
Запускайте безопасные приложения быстрее с Logto. Интегрируйте аутентификацию пользователей за считанные минуты и сосредоточьтесь на вашем основном продукте.
Добро пожаловать в руководство по подключению AI-инструментов к вашим существующим сервисам с контролем доступа!
Мы рассмотрим, как подготовить ваши существующие сервисы для AI-инструментов, особенно через интеграцию с LLM (с использованием Model Context Protocol) и различными AI-агентами, одновременно решая проблемы контроля доступа.
Из этого руководства вы узнаете:
Бесшовная интеграция AI: Узнайте, как подключать AI-инструменты к вашим сервисам, делая ваши данные и функционал доступными в AI-средах
Улучшенная безопасность API: Улучшите интерфейсы API для защиты данных и конфиденциальности пользователей с помощью эффективного контроля доступа
Индивидуальный AI-опыт для ваших пользователей: Создайте уникальные AI-ассистированные впечатления для каждого пользователя через Персональные Токены Доступа
Мы предоставляем полные учебные ресурсы, ПОЛНЫЙ ДЕМО-ПРОЕКТ ИСХОДНЫЙ КОД (ФРОНТЕНД, БЭКЕНД и MCP СЕРВЕР ВКЛЮЧЕНЫ), и практические руководства, которые помогут вам создать сервисы, готовые к AI, с нуля.
Вот как это руководство может улучшить ваш бизнес:
Конкурентное преимущество: Улучшите технические возможности и пользовательский опыт вашего сервиса, чтобы выделяться на конкурентном рынке
Увеличение ценности для пользователя: Позвольте пользователям открыть более глубокую ценность вашего продукта через AI-инструменты, увеличивая показатели удержания и удовлетворенности
Сервисы, готовые к будущему: Бесшовно интегрируйте ваши сервисы с AI-экосистемой, готовясь к грядущему бизнес-ландшафту, управляемому AI, и открывая инновационные пути роста
Давайте начнем!
Что такое MCP и как он подключает AI-инструменты к вашему сервису#
MCP (Model Context Protocol) - это открытый, универсальный протокол, стандартирующий способ предоставления контекстной информации для больших языковых моделей (LLMs) приложениями.
MCP состоит из нескольких ключевых компонентов, работающих вместе для обеспечения доступа AI-инструментов к вашим сервисам:
В этом руководстве вам нужно знать только то, что MCP Server - это ключевая точка соединения между вашим сервисом и AI-инструментами. Он отвечает за предоставление серии инструментов, которые LLM будет использовать, и эти инструменты будут взаимодействовать с вашими собственными сервисами. Для подробностей о MCP вы можете обратиться к What is MCP (Model Context Protocol) and how it works. Здесь мы сосредоточимся только на MCP Server.
Мы будем использовать систему управления контентом (CMS), в которой интегрированы политики контроля доступа на основе ролей (RBAC), в качестве нашего примера. Мы создадим для нее MCP Server и определим инструмент get-available-article-count, который позволит LLM получить количество статей, доступных текущему пользователю в CMS:
Это ключевой код для подключения MCP Server к вашему сервису. В этой реализации инструмента он отправляет запрос к api/articles вашего сервиса и возвращает результат.
Однако, это далеко не достаточно, потому что API вашего сервиса может не быть публичным. Каждый конечный пункт API требует контроля доступа, и разные пользователи могут иметь доступ к разным ресурсам и данным.
Поэтому далее мы обсудим, как добавить контроль доступа к вашему сервису.
Важно понять, что пользователи, получающие доступ к вашей системе через AI-инструменты, это те же самые люди, которые могут напрямую использовать вашу систему - MCP Server выступает их представителем, когда они взаимодействуют через AI-инструменты.
Поэтому, когда пользователи получают доступ к вашим сервисам через AI-инструменты, возникают две практические проблемы контроля доступа:
Как MCP Server может войти в вашу систему как пользователь?
Нужно ли вашей системе полностью переосмысливать свою механику контроля доступа только ради MCP Server? Это было бы значительными затратами и усилиями, особенно если ваша оригинальная система уже имеет собственный механизм аутентификации
Ключ к решению этих проблем заключается в следующем:
Как пользователи могут позволить MCP Server предоставить доступ из вашего сервиса без использования своих учетных данных и интерактивной авторизации?
Если вы сможете решить эту проблему, вы сможете напрямую взаимодействовать с вашим сервисом через MCP Server, и ваш сервис сможет продолжать использовать механизм контроля доступа, ранее разработанный для пользователей, без необходимости разрабатывать новую систему только для MCP Server!
Но возможно ли это?
Конечно, это возможно! Мы можем идеально решить эту проблему с помощью Персональных Токенов Доступа!
Персональные токены доступа (PATs) предоставляют безопасный способ для пользователей предоставлять токен доступа без использования их учетных данных и интерактивной авторизации. Это полезно для CI/CD, скриптов или приложений, которым необходимо программно получать доступ к ресурсам.
Вот как выглядит рабочий процесс:
Таким образом, пока ваша система поддерживает Персональные Токены Доступа (PAT), вы сможете идеально решить проблемы контроля доступа между AI-инструментами и вашими существующими сервисами без необходимости переосмысливать свои механизмы аутентификации, обеспечивая при этом безопасность данных и защиту конфиденциальности для ваших пользователей.
Теперь давайте посмотрим, как это реализовать на практике.
Пример CMS основан на Logto, популярной платформе открытого исходного кода для идентификации, которая предоставляет комплексное решение для аутентификации и авторизации, но техническая реализация не является фокусом этой статьи.
Проектирование политик доступа и контроля доступа для вашего сервиса#
Первым шагом в реализации контроля доступа является проектирование разрешений и политик контроля доступа для вашей системы.
В нашем примере CMS, мы разработали следующие конечные точки API на основе RBAC (Role-Based Access Control) и указали разрешения, необходимые для доступа к каждой конечной точке:
Конечная точка
Логика контроля доступа
GET /api/articles
- Любой с разрешением list:articles, ИЛИ авторы могут видеть свои собственные статьи
GET /api/articles/:id
- Любой с разрешением read:articles, ИЛИ автор статьи
POST /api/articles
- Любой с разрешением create:articles
PATCH /api/articles/:id
- Любой с разрешением update:articles, ИЛИ автор статьи
DELETE /api/articles/:id
- Любой с разрешением delete:articles, ИЛИ автор статьи
PATCH /api/articles/:id/published
- Только пользователи с разрешением publish:articles
Дизайн разрешений системы следующий:
Разрешение
Описание
list:articles
Просмотр списка всех статей в системе
read:articles
Чтение полного содержания любой статьи
create:articles
Создание новых статей
update:articles
Изменение любой статьи
delete:articles
Удаление любой статьи
publish:articles
Изменение статуса публикации
На основе этих разрешений мы определили следующие роли для нашей системы CMS:
Разрешение/Роль
👑 Администратор
📝 Издатель
✍️ Автор
Описание
Полный доступ к системе для полного управления контентом
Может просматривать все статьи и контролировать статус публикации
Может создавать новые статьи в системе
list:articles
✅
✅
❌
read:articles
✅
✅
❌
create:articles
✅
❌
✅
update:articles
✅
❌
❌
delete:articles
✅
❌
❌
publish:articles
✅
✅
❌
Примечание: Авторы автоматически имеют разрешения на чтение/изменение/удаление своих собственных статей, независимо от разрешений роли.
Далее, мы назначим роли пользователям в нашей системе (используя демо CMS в качестве примера):
Пользователь
Роль
Алекс
Администратор
Боб
Издатель
Чарли
Автор
И в Logto, как упомянуто в статье RBAC на практике, мы настроили роли для наших пользователей.
Применение политики контроля доступа к вашему сервису API#
Вот как пользователи входят в нашу CMS:
Таким образом, применение контроля доступа к вашему сервису API так же просто, как добавление промежуточного ПО для проверки токена доступа и проверки разрешений на шаге 9.
И примените промежуточное ПО к конечным точкам API, требующим аутентификации:
Теперь мы добавили контроль доступа в нашу систему CMS и назначили роли нашим пользователям.
После того, как пользователи войдут и получат свой токен доступа для CMS API, они могут использовать этот токен для доступа к CMS API. Токен доступа содержит информацию о разрешениях пользователя. Это позволяет нам контролировать, какие данные возвращать на основе разрешений пользователя.
Наш следующий шаг - реализовать MCP Server с использованием Персональных Токенов Доступа.
Понимание, как Персональный Токен Доступа представляет пользователей#
Ссылаясь на auth flow CMS выше, пользователи получают Токен Доступа для CMS API после входа. Этот Токен Доступа - их учетное данные для доступа к CMS API.
Нам просто нужно получить Токен Доступа, аналогичный тому, что пользователи получают после входа. Затем мы можем использовать его, чтобы получить доступ к CMS API.
Здесь и приходят на помощь Персональные Токены Доступа. Они помогают нам получить тот самый Токен Доступа, который пользователи обычно получают после входа.
Вот что нам нужно сделать:
Создать Персональный Токен Доступа для пользователя
Использовать этот Персональный Токен Доступа, чтобы запросить токен обмена у токенного конечного точки Auth-сервиса. Это дает нам Токен Доступа, как тот, который пользователи получают после входа
Использовать этот Токен Доступа в инструменте нашего MCP-сервера для доступа к CMS API
В этом примере мы используем Logto для демонстрации, так как Logto поддерживает Персональные Токены Доступа и обмен токенами. Если вы не используете Logto, вы можете следовать этому подходу для реализации собственной поддержки Персональных Токенов Доступа.
Создание Персонального Токена Доступа для вашего пользователя#
В Logto Console > Управление пользователями, вы можете создать Персональный Токен Доступа для пользователя на странице его/ее сведений:
При создании Персонального Токена Доступа вы можете установить его срок действия по мере необходимости.
Использование Персонального Токена Доступа в MCP сервере#
Теперь, когда у нас есть Персональный Токен Доступа пользователя, мы можем использовать его в нашем MCP сервере.
Сначала давайте следовать документации по Персональным Токенам Доступа Logto, получим Токен Доступа для доступа к API CMS от токенного конечного точки Logto. Вы можете посмотреть полный исходный код здесь.
На сервере MCP мы используем Токен Доступа от функции exchangeAccessToken для получения данных из CMS API.
Таким образом, MCP Server не требует учетных данных пользователя для входа в CMS API. Вместо этого он использует Персональный Токен Доступа пользователя.
Давайте протестируем эту реализацию на Claude Desktop.
В нашей CMS как Алекс, так и Чарли создали по одной статье.
Так как Алекс имеет роль Администратора, он может видеть все статьи. Чарли, будучи Автором, может видеть только свои собственные статьи.
Когда мы спрашиваем Claude, сколько доступных статей, Claude использует инструмент get-available-article-count и спрашивает наше разрешение:
Когда мы используем Персональный Токен Доступа Алекса в MCP и спрашиваем Claude о количестве доступных статей, Claude вызывает инструмент get-available-article-count и сообщает нам, что есть 2 статьи.
Когда мы переключаемся на Персональный Токен Доступа Чарли и задаем тот же вопрос, Claude говорит нам, что есть только 1 статья.
Отлично! Мы успешно использовали Персональные Токены Доступа для доступа к CMS API и получения правильных данных.
Это именно то, что мы хотели: мы создаем Персональный Токен Доступа для каждого пользователя, и когда пользователи настраивают свой MCP Server с их токеном, мы создаем для них персонализированный AI-опыт.
Позвольте мне помочь вам написать раздел "Резюме":
В этом руководстве мы рассмотрели, как подключить AI-инструменты к вашим существующим сервисам, при этом сохраняя надлежащий контроль доступа. Мы продемонстрировали это на примере системы CMS с реализацией RBAC, показав, как Персональные Токены Доступа могут изящно решить проблемы аутентификации.
Вы можете найти полный исходный код этой реализации в нашем репозитории образцов RBAC, который включает бэкенд CMS, фронтенд и реализацию MCP сервера.
При распределении вашего MCP server пользователям, помните о необходимости сделать Персональный Токен Доступа настраиваемым. Это позволит каждому пользователю:
Настроить свой собственный PAT в MCP server
Получать доступ к ресурсам на основе их конкретных разрешений
Получать персонализированный AI-опыт, отражающий их роль и уровень доступа в вашей системе
Этот подход обеспечивает, что ваша AI-интеграция остается безопасной, предоставляя индивидуальный опыт для каждого пользователя на основе их разрешений и роли в вашей системе.
Желаю вам огромного успеха в вашем бизнесе, когда вы начнете эту AI-интеграцию! Пусть ваши услуги процветают и растут с этими новыми AI-возможностями! 🚀