Autenticación

Las claves de producción de Model Gate comienzan con mg_live_. La misma clave funciona para solicitudes compatibles con OpenAI y Anthropic.

Encabezado compatible con OpenAI

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

Utilice este formulario para /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, y /v1/balance.

Encabezado compatible con antrópicos

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

Utilice este formulario para /v1/messages y /v1/messages/count_tokens. También se acepta la autenticación del portador.

Ejemplo de solicitud

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

Ejemplo de respuesta

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

Puntos finales no autenticados

Solo los puntos finales de estado del servicio no están autenticados:

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

Sesiones de navegador interactivo

El panel de la cuenta de Model Gate utiliza una sesión de navegador del lado del servidor que está separada de las claves de Model API. De forma predeterminada, una sesión de navegador autenticada caduca después 12 horas sin actividad autenticada o después 7 días en total, lo que ocurra primero. La cookie del navegador en sí sigue siendo una cookie de sesión, por lo que cerrar el navegador puede finalizarlo antes dependiendo del comportamiento del navegador.

Cuando una página del panel de cuenta todavía está abierta después de que expire la autenticación, las acciones AJAX devuelven HTTP 401 JSON con código authentication_required y el panel muestra un La sesión expiró mensaje en lugar de tratar la página de inicio de sesión como JSON. Una página obsoleta/token CSRF devuelve HTTP 419 JSON con código csrf_expired y solicita una actualización de la página. Las mutaciones fallidas, incluida la inicialización del pago, nunca se reproducen automáticamente después de iniciar sesión o actualizar.

Seguridad de cuenta e IP

El perfil autenticado puede habilitar la autenticación TOTP de dos factores con WinAuth u otro autenticador compatible. Las organizaciones empresariales pueden exigir TOTP para cada miembro; este requisito está habilitado de forma predeterminada para las organizaciones empresariales. Un desafío de segundo factor completado se registra en la sesión actual del navegador. Las acciones sensibles de la cuenta, como crear/revelar/rotar credenciales, cambiar la política de seguridad y regenerar secretos de seguridad, requieren una prueba reciente de segundo factor cuando TOTP está habilitado; la ventana del producto actual es de 15 minutos.

Habilitar TOTP crea diez códigos de recuperación únicos. Sus valores completos se muestran sólo cuando se generan; Model Gate almacena solo hashes y consume atómicamente un código después de su uso. La regeneración de códigos de recuperación invalida los códigos antiguos no utilizados. La inscripción TOTP requiere la contraseña actual cuando la cuenta tiene una, o una autenticación primaria reciente de OAuth/Telegram para cuentas sin contraseña. Los cambios de contraseña, la activación/desactivación/restablecimiento de TOTP y los cambios en la política de seguridad de inicio de sesión revocan las sesiones obsoletas del navegador. Los administradores y los usuarios propietarios/administradores de la empresa pueden restablecer el TOTP de un usuario administrado cuando se requiere recuperación; ese reinicio cierra las sesiones del navegador del objetivo pero no revoca las credenciales de Model API.

El perfil presenta Aplicación de autenticación (TOTP) y Listas de IP permitidas como controles de seguridad separados. La inscripción inicial del autenticador abre un modal y completa la configuración/confirmación con AJAX mientras se conserva el respaldo POST normal del lado del servidor. Las listas permitidas de inicio de sesión/API se editan en un modo separado y se guardan con AJAX después de la misma política intensificada reciente de 2FA.

El perfil también admite listas de inicio de sesión independientes y de IP de API permitidas. Las reglas son direcciones IPv4/IPv6 exactas o prefijos CIDR. Una lista vacía significa que no hay restricciones. Los propietarios/administradores de empresas también pueden definir listas de inicio de sesión y API permitidas para toda la organización. Cuando existen reglas de API tanto personales como de organización, el origen de la solicitud debe coincidir con ambas. Una solicitud rechazada por una política IP de API devuelve HTTP 403 con codigo ip_not_allowed donde el formato de respuesta de compatibilidad expone un código de error.

Para las credenciales comerciales, el propietario de la empresa sigue siendo el propietario de la facturación, mientras que cada credencial registra un usuario de credencial (principal). El estado activo del principal, la lista de IP permitidas de API personal y los límites de RPM/concurrencia del usuario se aplican a esa clave; el equilibrio/precios de la empresa y la política de propiedad intelectual de API de la organización siguen estando dentro del alcance de la empresa. Las credenciales de empleado deben asignarse a un grupo activo y requieren un permiso comercial ejecutable (admin o developer, también se acepta la autoridad de propietario/administrador de la organización). billing y viewer Los permisos de grupo no ejecutan el tráfico de la API del modelo.

Un administrador de grupo puede administrar claves en ese grupo, pero no puede revelar ni rotar un secreto emitido a otra entidad principal de credenciales; el propio director y el propietario/administrador de la organización pueden acceder a ese secreto de credencial. Si un secreto de propietario-principal se compartió con los empleados antes de la versión 9.6.2, rótelo y emita credenciales de empleado-principal dedicadas para obtener un comportamiento confiable de revocación/IP por empleado.

TOTP protege el inicio de sesión interactivo y las acciones sensibles de cuentas humanas. La contraseña, el inicio de sesión de OAuth y Telegram utilizan la misma política de segundo factor. Los códigos de recuperación se pueden usar una vez en lugar de TOTP para iniciar sesión o avanzar. Los comandos confidenciales de Telegram requieren un segundo factor cuando TOTP está inscrito, y los códigos enviados se eliminan del almacenamiento duradero de actualizaciones/conversaciones de Telegram. Las solicitudes de API modelo sí lo hacen. no solicitar o validar un código TOTP: una clave ya emitida está autorizada por el estado de la clave, el estado/permisos del principal de la credencial, las listas permitidas de IP efectivas y los límites de tiempo de ejecución/facturación.

• Almacene claves en variables de entorno o en un administrador secreto.
• Nunca envíes una clave a Git.
• Utilice una clave separada para cada proyecto o usuario externo.
• Congele o gire una clave comprometida inmediatamente.
• Los secretos de clave API del modelo se muestran solo en el momento de la creación o rotación.
• Partner API tokens de portador también se muestran solo en la generación/rotación y Model Gate los almacena solo mediante hash.
• Los secretos de firma de devolución de llamada se muestran solo durante la generación/rotación y se cifran en reposo; guarde su copia en un administrador secreto.
• Si habilita una lista de IP permitidas de API, incluya todas las direcciones NAT/de salida salientes que puedan llamar a Model Gate.