Autenticació

Les claus de producció de Model Gate comencen amb mg_live_. La mateixa clau funciona per a sol·licituds compatibles amb OpenAI i Anthropic.

Capçalera compatible amb OpenAI

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

Utilitzeu aquest formulari per /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, i /v1/balance.

Capçalera compatible amb antròpics

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

Utilitzeu aquest formulari per /v1/messages i /v1/messages/count_tokens. També s'accepta l'autenticació del portador.

Exemple de petició

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

Exemple de resposta

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

Punts finals no autenticats

Només els punts finals de salut del servei no estan autenticats:

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

Sessions interactives del navegador

El tauler de compte de Model Gate utilitza una sessió del navegador del servidor que és independent de les claus de l'API Model. Per defecte, una sessió de navegador autenticada caduca després 12 hores sense activitat autenticada o després 7 dies en total, el que passi primer. La galeta del navegador en si segueix sent una galeta de sessió, de manera que el tancament del navegador pot finalitzar-lo abans depenent del comportament del navegador.

Quan una pàgina del tauler de compte encara està oberta després de caducar l'autenticació, les accions AJAX retornen HTTP 401 JSON amb codi authentication_required i el panell mostra a La sessió ha caducat prompte en lloc de tractar la pàgina d'inici de sessió com a JSON. Un testimoni de pàgina/CSRF obsolet retorna HTTP 419 JSON amb codi csrf_expired i demana una actualització de la pàgina. Les mutacions fallides, inclosa la inicialització del pagament, no es reprodueixen mai automàticament després d'iniciar la sessió o actualitzar-les.

Seguretat del compte i de la IP

El perfil autenticat pot habilitar l'autenticació de dos factors TOTP amb WinAuth o un altre autenticador compatible. Les organitzacions empresarials poden requerir TOTP per a cada membre; aquest requisit està habilitat per defecte per a les organitzacions empresarials. Es registra un repte de segon factor completat a la sessió actual del navegador. Les accions sensibles del compte, com ara crear/revelar/rotar credencials, canviar la política de seguretat i regenerar secrets de seguretat, requereixen una prova recent de segon factor quan TOTP està habilitat; la finestra actual del producte és de 15 minuts.

L'habilitació de TOTP crea deu codis de recuperació únics. Els seus valors complets només es mostren quan es generen; Model Gate només emmagatzema hash i consumeix atòmicament un codi després del seu ús. La regeneració dels codis de recuperació invalida els codis antics no utilitzats. La inscripció TOTP requereix la contrasenya actual quan el compte en té una, o una autenticació primària OAuth/Telegram recent per als comptes sense contrasenya. Els canvis de contrasenya, l'activació/desactivació/restabliment de TOTP i els canvis a la política de seguretat d'inici de sessió revoquen les sessions obsoletes del navegador. Els administradors i els usuaris propietaris/administradors de l'empresa poden restablir el TOTP d'un usuari gestionat quan calgui la recuperació; aquest restabliment tanca les sessions del navegador de l'objectiu, però no revoca les credencials de l'API del model.

El perfil presenta Aplicació d'autenticació (TOTP) i Llistes permeses d'IP com a controls de seguretat separats. La inscripció inicial de l'autenticador obre un modal i completa la configuració/confirmació amb AJAX mentre es manté la alternativa POST normal del costat del servidor. Les llistes de permís d'inici de sessió/API s'editen en un modal separat i es guarden amb AJAX després de la mateixa política d'increment de 2FA recent.

El perfil també admet llistes d'accés i IP d'API separades. Les regles són adreces IPv4/IPv6 exactes o prefixos CIDR. Una llista buida significa cap restricció. Els propietaris/administradors d'empreses poden definir, a més, llistes de permisos d'API i d'inici de sessió a tota l'organització. Quan existeixen regles d'API tant personals com organitzatives, la font de sol·licitud ha de coincidir amb totes dues. Una sol·licitud rebutjada per una política IP de l'API retorna HTTP 403 amb codi ip_not_allowed on el format de resposta de compatibilitat exposa un codi d'error.

Per a les credencials empresarials, el propietari de l'empresa continua sent el propietari de la facturació mentre que cada credencial registra un usuari de credencial (principal). A aquesta clau s'apliquen l'estat actiu del director, la llista personal d'IP de l'API i els límits de RPM/concurrència de l'usuari; el saldo/preus de l'empresa i la política de propietat intel·lectual de l'API de l'organització segueixen l'àmbit de l'empresa. Les credencials dels empleats s'han d'assignar a un grup actiu i requereixen un permís empresarial executable (admin o developer, amb l'autoritat del propietari/administrador de l'organització també acceptada). billing i viewer els permisos de grup no executen el trànsit de l'API del model.

Un administrador de grup pot gestionar les claus d'aquest grup, però no pot revelar ni rotar un secret emès a un altre principal de credencials; el propi principal i el propietari/administrador de l'organització poden accedir a aquest secret de credencial. Si un secret principal del propietari es va compartir amb els empleats abans de la 9.6.2, gireu-lo i emeteu credencials de director d'empleat dedicades per obtenir un comportament de revocació/IP fiable per empleat.

TOTP protegeix l'inici de sessió interactiu i les accions sensibles del compte humà. L'inici de sessió amb contrasenya, OAuth i Telegram utilitzen la mateixa política de segon factor. Els codis de recuperació es poden utilitzar una vegada en lloc de TOTP per iniciar la sessió o augmentar-lo. Les ordres sensibles de Telegram requereixen un segon factor quan s'inscriu TOTP i els codis enviats s'eliminen de l'emmagatzematge durador d'actualitzacions/converses de Telegram. Les sol·licituds d'API de models sí no sol·licitar o validar un codi TOTP: una clau ja emesa està autoritzada per l'estat de la clau, l'estat/permisos de la credencial principal, les llistes d'IP efectives i els límits d'execució/facturació.

• Emmagatzema les claus en variables d'entorn o en un gestor secret.
• No comprometeu mai una clau a Git.
• Utilitzeu una clau independent per a cada projecte o usuari extern.
• Congela o gira una clau compromesa immediatament.
• Els secrets de la clau de l'API del model només es mostren en la creació o la rotació.
• Les fitxes del portador Partner API també es mostren només a la generació/rotació i Model Gate només emmagatzemen com a hash.
• Els secrets de signatura de devolució de trucada només es mostren durant la generació/rotació i es xifren en repòs; emmagatzema la teva còpia en un gestor secret.
• Si activeu una llista d'IP permeses d'API, incloeu totes les adreces de sortida/NAT de sortida que puguin trucar a Model Gate.