Authentification

Les clés de production de Model Gate commencent par mg_live_. La même clé fonctionne pour les requêtes compatibles OpenAI et Anthropic.

En-tête compatible OpenAI

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

Utilisez ce formulaire pour /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, et /v1/balance.

En-tête compatible anthropique

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

Utilisez ce formulaire pour /v1/messages et /v1/messages/count_tokens. L'authentification du porteur est également acceptée.

Exemple de demande

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

Exemple de réponse

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

Points de terminaison non authentifiés

Seuls les points de terminaison d’intégrité du service ne sont pas authentifiés :

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

Sessions de navigateur interactives

Le panneau de compte Model Gate utilise une session de navigateur côté serveur distincte des clés API Model. Par défaut, une session de navigateur authentifiée expire après 12 heures sans activité authentifiée ou après 7 jours au total, selon la première éventualité. Le cookie du navigateur lui-même reste un cookie de session, donc la fermeture du navigateur peut y mettre fin plus tôt en fonction du comportement du navigateur.

Lorsqu'une page du panneau de compte est toujours ouverte après l'expiration de l'authentification, les actions AJAX renvoient HTTP 401 JSON avec code authentication_required et le panneau montre un Session expirée invite au lieu de traiter la page de connexion comme JSON. Une page obsolète/un jeton CSRF renvoie HTTP 419 JSON avec code csrf_expired and asks for a page refresh. Les mutations ayant échoué, y compris l'initialisation du paiement, ne sont jamais automatiquement rejouées après la connexion ou l'actualisation.

Sécurité du compte et de l'IP

Le profil authentifié peut activer l'authentification à deux facteurs TOTP avec WinAuth ou un autre authentificateur compatible. Les organisations commerciales peuvent exiger le TOTP pour chaque membre ; cette exigence est activée par défaut pour les organisations professionnelles. Un défi de deuxième facteur terminé est enregistré sur la session de navigateur en cours. Les actions de compte sensibles telles que la création/révélation/rotation d'informations d'identification, la modification de la politique de sécurité et la régénération des secrets de sécurité nécessitent une preuve récente de deuxième facteur lorsque TOTP est activé ; la fenêtre actuelle du produit est de 15 minutes.

Enabling TOTP creates ten one-time recovery codes. Their full values are shown only when generated; Model Gate stores only hashes and atomically consumes a code after use. Regenerating recovery codes invalidates older unused codes. TOTP enrollment requires the current password when the account has one, or a recent primary OAuth/Telegram authentication for passwordless accounts. Password changes, TOTP enable/disable/reset and login-security policy changes revoke stale browser sessions. Administrators and Business owner/admin users can reset a managed user's TOTP when recovery is required; cette réinitialisation déconnecte les sessions du navigateur de la cible mais ne révoque pas les informations d'identification de l'API du modèle.

Le profil présente Application d'authentification (TOTP) et Listes autorisées d'adresses IP as separate security controls. L'inscription initiale de l'authentificateur ouvre un modal et termine la configuration/confirmation avec AJAX tout en conservant le repli POST normal côté serveur. Les listes autorisées de connexion/API sont modifiées dans un modal distinct et enregistrées avec AJAX après la même politique d'intensification récente de 2FA.

Le profil prend également en charge des listes d'autorisation de connexion et d'adresse IP d'API distinctes. Les règles sont des adresses IPv4/IPv6 exactes ou des préfixes CIDR. Une liste vide signifie aucune restriction. Les propriétaires/administrateurs d’entreprise peuvent en outre définir des listes autorisées de connexion et d’API à l’échelle de l’organisation. Lorsque des règles API personnelles et organisationnelles existent, la source de la demande doit correspondre aux deux. Une requête rejetée par une politique IP API renvoie HTTP 403 avec code ip_not_allowed où le format de réponse de compatibilité expose un code d'erreur.

Pour les identifiants Business, le propriétaire de l'entreprise reste le propriétaire de la facturation tandis que chaque identifiant enregistre un utilisateur d'identifiant (principal). Le statut actif du principal, la liste blanche d'adresses IP de l'API personnelle et les limites de RPM/de concurrence de l'utilisateur s'appliquent à cette clé ; l'équilibre/les prix de l'entreprise et la politique IP de l'API de l'organisation restent à l'échelle de l'entreprise. Les informations d'identification des employés doivent être attribuées à un groupe actif et nécessitent une autorisation professionnelle exécutable (admin ou developer, avec l'autorité de propriétaire/administrateur de l'organisation également acceptée). billing et viewer les autorisations de groupe n'exécutent pas le trafic de l'API modèle.

Un administrateur de groupe peut gérer les clés de ce groupe, mais ne peut pas révéler ou alterner un secret délivré à un autre principal d'informations d'identification ; le directeur lui-même et le propriétaire/administrateur de l'organisation peuvent accéder à ce secret d'identification. Si un secret principal de propriétaire a été partagé avec des employés avant la version 9.6.2, faites-le alterner et émettez des informations d'identification principales d'employé dédiées pour obtenir un comportement de révocation/IP fiable par employé.

TOTP protège la connexion interactive et les actions sensibles des comptes humains. La connexion par mot de passe, OAuth et Telegram utilise tous la même politique de deuxième facteur. Les codes de récupération peuvent être utilisés une fois à la place du TOTP pour la connexion ou la mise à niveau. Les commandes Telegram sensibles nécessitent un deuxième facteur lorsque TOTP est inscrit, et les codes soumis sont rédigés à partir du stockage durable de mise à jour/conversation Telegram. Les requêtes API de modèle le font pas demander ou valider un code TOTP : une clé déjà émise est autorisée par l'état de la clé, le statut/les autorisations des informations d'identification et du principal, les listes d'autorisation IP effectives et les limites d'exécution/de facturation.

• Stockez les clés dans des variables d'environnement ou dans un gestionnaire de secrets.
• Ne validez jamais une clé dans Git.
• Utilisez une clé distincte pour chaque projet ou utilisateur externe.
• Gelez ou faites pivoter une clé compromise immédiatement.
• Les secrets de clé API du modèle sont affichés uniquement lors de la création ou de la rotation.
• Partner API jetons de porteur sont également affichés uniquement lors de la génération/rotation et sont stockés uniquement en hachage par Model Gate.
• Les secrets de signature de rappel sont affichés uniquement lors de la génération/rotation et sont chiffrés au repos ; stockez votre copie dans un gestionnaire de secrets.
• Si vous activez une liste blanche d'adresses IP d'API, incluez chaque adresse NAT/sortie sortante pouvant appeler Model Gate.