Аутентификация

Ключи производства Model Gate начинаются с mg_live_. Тот же ключ работает для запросов, совместимых с OpenAI и Anthropic.

OpenAI-совместимый заголовок

Authorization: Bearer mg_live_...
Content-Type: application/json

Используйте эту форму для /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, и /v1/balance.

Антропно-совместимый заголовок

x-api-key: mg_live_...
anthropic-version: 2023-06-01
content-type: application/json

Используйте эту форму для /v1/messages и /v1/messages/count_tokens. Аутентификация носителя также принимается.

Пример запроса

curl https://api.model-gate.com/v1/models \
  -H "Authorization: Bearer mg_live_..."

Пример ответа

{
  "object": "list",
  "data": []
}

Неаутентифицированные конечные точки

Только конечные точки работоспособности службы не проходят проверку подлинности:

GET /health
GET /health/live
GET /health/ready

Интерактивные сеансы браузера

Панель учетной записи Model Gate использует сеанс браузера на стороне сервера, который отделен от ключей Model API. По умолчанию срок действия аутентифицированного сеанса браузера истекает после 12 часов без подтвержденной активности или после всего 7 дней, в зависимости от того, что наступит раньше. Файл cookie браузера сам по себе остается сеансовым файлом cookie, поэтому закрытие браузера может завершить его раньше в зависимости от поведения браузера.

Если страница панели учетной записи все еще открыта после истечения срока аутентификации, действия AJAX возвращают HTTP. 401 JSON с кодом authentication_required и на панели отображается Срок сеанса истек подсказку вместо обработки страницы входа в формате JSON. Устаревшая страница/токен CSRF возвращает HTTP 419 JSON с кодом csrf_expired и просит обновить страницу. Неудачные изменения, включая инициализацию платежа, никогда не воспроизводятся автоматически после входа в систему или обновления.

Безопасность аккаунта и IP

Аутентифицированный профиль может включить двухфакторную аутентификацию TOTP с помощью WinAuth или другого совместимого аутентификатора. Бизнес-организации могут требовать TOTP для каждого члена; это требование включено по умолчанию для бизнес-организаций. Завершенное испытание второго фактора записывается в текущем сеансе браузера. Действия с конфиденциальной учетной записью, такие как создание, раскрытие или смена учетных данных, изменение политики безопасности и повторное создание секретов безопасности, требуют недавнего подтверждения второго фактора при включении TOTP; текущее окно продукта составляет 15 минут.

Включение TOTP создает десять одноразовых кодов восстановления. Их полные значения отображаются только после создания; Model Gate хранит только хэши и атомарно потребляет код после использования. Повторное создание кодов восстановления делает недействительными старые неиспользованные коды. Для регистрации TOTP требуется текущий пароль, если он есть у учетной записи, или недавняя основная аутентификация OAuth/Telegram для учетных записей без пароля. Изменение пароля, включение/отключение/сброс TOTP и изменения политики безопасности входа в систему отменяют устаревшие сеансы браузера. Администраторы и владельцы/администраторы бизнеса могут сбросить TOTP управляемого пользователя, когда требуется восстановление; этот сброс завершает сеансы целевого браузера, но не отзывает учетные данные Model API.

В профиле представлены Приложение для аутентификации (TOTP) и Белые списки IP-адресов как отдельные средства контроля безопасности. Первоначальная регистрация аутентификатора открывает модальное окно и завершает настройку/подтверждение с помощью AJAX, сохраняя при этом обычный резервный вариант POST на стороне сервера. Списки разрешений входа/API редактируются в отдельном модальном окне и сохраняются с помощью AJAX после той же политики недавнего повышения уровня 2FA.

Профиль также поддерживает отдельные списки разрешенных IP-адресов для входа и API. Правила — это точные адреса IPv4/IPv6 или префиксы CIDR. Пустой список означает отсутствие ограничений. Владельцы/администраторы бизнеса могут дополнительно определять списки разрешенных входов и API для всей организации. Если существуют как личные, так и организационные правила API, источник запроса должен соответствовать обоим. Запрос, отклоненный политикой API IP, возвращает HTTP. 403 с кодом ip_not_allowed где формат ответа совместимости предоставляет код ошибки.

Для бизнес-учетных данных владелец компании остается владельцем выставления счетов, а в каждых учетных данных записывается пользователь учетных данных (принципал). К этому ключу применяются активный статус принципала, личный список разрешенных IP-адресов API и ограничения RPM/параллелизма пользователя; баланс компании/ценообразование и IP-политика API организации остаются в рамках компании. Учетные данные сотрудника должны быть назначены активной группе и требуют исполняемого бизнес-разрешения (admin или developer, также принимаются полномочия владельца/администратора организации). billing и viewer групповые разрешения не обрабатывают трафик Model API.

Администратор группы может управлять ключами в этой группе, но не может раскрывать или менять секрет, выданный другому субъекту учетных данных; сам принципал и владелец/администратор организации могут получить доступ к этому секрету учетных данных. Если секрет владельца и принципала был передан сотрудникам до версии 9.6.2, поменяйте его и выдайте специальные учетные данные сотрудника и принципала, чтобы обеспечить надежное поведение при отзыве IP-адресов для каждого сотрудника.

TOTP защищает интерактивный вход и конфиденциальные действия с учетной записью человека. Пароль, OAuth и вход в Telegram используют одну и ту же политику второго фактора. Коды восстановления можно использовать один раз вместо TOTP для входа в систему или повышения уровня. Для конфиденциальных команд Telegram требуется второй фактор при регистрации TOTP, а отправленные коды удаляются из надежного хранилища обновлений/разговоров Telegram. Запросы API модели делают нет запросить или проверить код TOTP: уже выданный ключ авторизован состоянием ключа, статусом/разрешениями субъекта учетных данных, действующими списками разрешенных IP-адресов и ограничениями времени выполнения/выставления счетов.

• Храните ключи в переменных среды или в секретном менеджере.
• Никогда не передавайте ключ в Git.
• Используйте отдельный ключ для каждого проекта или внешнего пользователя.
• Немедленно заморозьте или поверните скомпрометированный ключ.
• Секреты ключа API модели отображаются только при создании или ротации.
• Токены носителя Partner API также отображаются только при генерации/ротации и хранятся только в виде хэша в Model Gate.
• Секреты подписи обратного вызова отображаются только при генерации/ротации и шифруются в состоянии покоя; сохраните свою копию в секретном менеджере.
• Если вы включаете список разрешенных IP-адресов API, включите каждый исходящий NAT/исходящий адрес, который может вызывать Model Gate.