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

Аутентификация всех запросов API Model Gate с помощью одного производственного ключа API.

Ключи производства 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 включен; окно подтверждения по умолчанию составляет 60 минут (настраивается TWO_FACTOR_STEP_UP_TTL_SECONDS). Это не меняет 30-секундный период кода аутентификатора.

Включение 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.

Общие ключи проекта в Playground

Разработчики и администраторы бизнес-проектов могут выбирать ключи проекта в Playground, даже если ключ создал другой участник. Временные учетные данные браузера используют вошедшего в систему сотрудника в качестве удостоверения выполнения: применяются его текущие групповые разрешения, личная IP-политика API и ограничения для каждого пользователя. Использование ключа/группы и фактическое выставление счетов остаются за компанией. Это не раскрывает секрет многоразового ключа другого участника и не дает разработчику доступ к кошельку компании. Сеансы браузера не могут отправлять отложенные асинхронные или пакетные задания; используйте для этих интеграций специальные долгосрочные учетные данные.

Чтение элементов управления использованием

Отображение ключей API и групп ключей Лимит использования, долл. США против возобновляемого использования, а не за весь срок службы. Соблюдаются как ключевые, так и групповые ограничения; ноль удаляет только потолок на этом объекте. RPM и параллелизм — это отдельные ограничения на количество запросов, а доступный баланс кошелька — еще одно необходимое условие.

Владелец группы может выбрать Сбросить использование в Группах после обычного подтверждения безопасности. При этом очищается только групповой счетчик; сброс ключа в расширенной строке «Ключи API» очищает только этот ключ. Ни одно из действий не возвращает платеж, не изменяет расходы за весь период и не удаляет запросы. Оставшаяся квота и время последнего сброса отображаются рядом с элементами управления.

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