Authentifizierung

Die Produktionsschlüssel für Model Gate beginnen mit mg_live_. Der gleiche Schlüssel funktioniert für OpenAI-kompatible und Anthropic-kompatible Anfragen.

OpenAI-kompatibler Header

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

Verwenden Sie dieses Formular für /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, Und /v1/balance.

Anthropic-kompatibler Header

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

Verwenden Sie dieses Formular für /v1/messages Und /v1/messages/count_tokens. Eine Inhaberauthentifizierung wird ebenfalls akzeptiert.

Beispiel anfordern

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

Antwortbeispiel

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

Nicht authentifizierte Endpunkte

Nur Service-Health-Endpunkte sind nicht authentifiziert:

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

Interaktive Browsersitzungen

Das Model Gate-Kontofenster verwendet eine serverseitige Browsersitzung, die von den Model-API-Schlüsseln getrennt ist. Standardmäßig läuft eine authentifizierte Browsersitzung danach ab 12 Stunden ohne authentifizierte Aktivität oder danach Insgesamt 7 Tage, je nachdem, was zuerst eintritt. Das Browser-Cookie selbst bleibt ein Sitzungscookie, sodass es je nach Browserverhalten beim Schließen des Browsers früher beendet werden kann.

Wenn eine Kontofensterseite nach Ablauf der Authentifizierung noch geöffnet ist, geben AJAX-Aktionen HTTP zurück 401 JSON mit Code authentication_required und das Panel zeigt a Sitzung abgelaufen Eingabeaufforderung, anstatt die Anmeldeseite als JSON zu behandeln. Ein veraltetes Seiten-/CSRF-Token gibt HTTP zurück 419 JSON mit Code csrf_expired und bittet um eine Seitenaktualisierung. Fehlgeschlagene Mutationen, einschließlich der Zahlungsinitialisierung, werden nach der Anmeldung oder Aktualisierung nie automatisch wiederholt.

Konto- und IP-Sicherheit

Das authentifizierte Profil kann die TOTP-Zwei-Faktor-Authentifizierung mit WinAuth oder einem anderen kompatiblen Authentifikator ermöglichen. Unternehmensorganisationen verlangen möglicherweise TOTP für jedes Mitglied; Diese Anforderung ist für Unternehmensorganisationen standardmäßig aktiviert. Eine abgeschlossene Zweitfaktor-Herausforderung wird in der aktuellen Browsersitzung aufgezeichnet. Sensible Kontoaktionen wie das Erstellen/Offenlegen/Rotieren von Anmeldeinformationen, das Ändern von Sicherheitsrichtlinien und das Neuerstellen von Sicherheitsgeheimnissen erfordern einen aktuellen Zweitfaktornachweis, wenn TOTP aktiviert ist; Das aktuelle Produktfenster beträgt 15 Minuten.

Durch die Aktivierung von TOTP werden zehn einmalige Wiederherstellungscodes erstellt. Ihre vollständigen Werte werden erst angezeigt, wenn sie generiert werden. Model Gate speichert nur Hashes und verbraucht einen Code nach der Verwendung atomar. Durch die Neugenerierung von Wiederherstellungscodes werden ältere nicht verwendete Codes ungültig. Für die TOTP-Registrierung ist das aktuelle Passwort erforderlich, wenn das Konto eines hat, oder eine aktuelle primäre OAuth/Telegram-Authentifizierung für passwortlose Konten. Passwortänderungen, TOTP-Aktivierung/Deaktivierung/Zurücksetzen und Änderungen der Anmeldesicherheitsrichtlinien widerrufen veraltete Browsersitzungen. Administratoren und Geschäftsinhaber/Administratorbenutzer können den TOTP eines verwalteten Benutzers zurücksetzen, wenn eine Wiederherstellung erforderlich ist. Durch dieses Zurücksetzen werden die Browsersitzungen des Ziels abgemeldet, die Model-API-Anmeldeinformationen werden jedoch nicht widerrufen.

Das Profil präsentiert Authentifizierungs-App (TOTP) Und IP-Zulassungslisten als separate Sicherheitskontrollen. Die anfängliche Authentifikatorregistrierung öffnet ein Modal und schließt die Einrichtung/Bestätigung mit AJAX ab, während der normale serverseitige POST-Fallback beibehalten wird. Anmelde-/API-Zulassungslisten werden in einem separaten Modal bearbeitet und mit AJAX nach derselben aktuellen 2FA-Step-up-Richtlinie gespeichert.

Das Profil unterstützt auch separate Anmelde- und API-IP-Zulassungslisten. Regeln sind genaue IPv4/IPv6-Adressen oder CIDR-Präfixe. Eine leere Liste bedeutet keine Einschränkung. Geschäftsinhaber/Administratoren können zusätzlich organisationsweite Anmelde- und API-Zulassungslisten definieren. Wenn sowohl persönliche als auch organisatorische API-Regeln vorhanden sind, muss die Anforderungsquelle mit beiden übereinstimmen. Eine von einer API-IP-Richtlinie abgelehnte Anfrage gibt HTTP zurück 403 mit Code ip_not_allowed wobei das Kompatibilitätsantwortformat einen Fehlercode offenlegt.

Bei Business-Zugangsdaten bleibt der Firmeneigentümer der Rechnungseigentümer, während bei jedem Zugangsnachweis ein Zugangsdatenbenutzer (Principal) erfasst wird. Für diesen Schlüssel gelten der aktive Status des Prinzipals, die persönliche API-IP-Zulassungsliste und die RPM-/Parallelitätsbeschränkungen des Benutzers. Die Balance/Preise des Unternehmens und die IP-Richtlinie der Organisations-API bleiben unternehmensspezifisch. Mitarbeiterzugangsdaten müssen einer aktiven Gruppe zugewiesen werden und erfordern eine ausführbare Geschäftsberechtigung (admin oder developer, wobei auch Organisationseigentümer-/Administratorberechtigungen akzeptiert werden). billing Und viewer Gruppenberechtigungen führen keinen Modell-API-Verkehr aus.

Ein Gruppenadministrator kann Schlüssel in dieser Gruppe verwalten, jedoch kein Geheimnis offenlegen oder rotieren, das an einen anderen Anmeldeinformationsprinzipal ausgegeben wurde. Der Auftraggeber selbst und der Eigentümer/Administrator der Organisation können auf dieses Anmeldeinformationsgeheimnis zugreifen. Wenn ein Eigentümer-Principal-Geheimnis vor 9.6.2 mit Mitarbeitern geteilt wurde, rotieren Sie es und stellen Sie dedizierte Mitarbeiter-Principal-Zugangsdaten aus, um ein zuverlässiges Widerrufs-/IP-Verhalten pro Mitarbeiter zu erhalten.

TOTP schützt die interaktive Anmeldung und sensible Benutzerkontoaktionen. Passwort, OAuth und Telegram-Anmeldung verwenden alle dieselbe Zweitfaktor-Richtlinie. Wiederherstellungscodes können einmalig anstelle von TOTP für die Anmeldung oder den Step-Up verwendet werden. Sensible Telegram-Befehle erfordern einen zweiten Faktor, wenn TOTP registriert wird, und übermittelte Codes werden aus dem dauerhaften Telegram-Aktualisierungs-/Konversationsspeicher geschwärzt. Modell-API-Anfragen tun dies nicht Aufforderung zur Eingabe oder Validierung eines TOTP-Codes: Ein bereits ausgegebener Schlüssel wird durch den Schlüsselstatus, den Status/Berechtigungen des Anmeldeinformationsprinzips, effektive IP-Zulassungslisten und Laufzeit-/Abrechnungslimits autorisiert.

• Speichern Sie Schlüssel in Umgebungsvariablen oder einem Secret Manager.
• Übergeben Sie niemals einen Schlüssel an Git.
• Verwenden Sie für jedes Projekt oder jeden externen Benutzer einen separaten Schlüssel.
• Einen kompromittierten Schlüssel sofort einfrieren oder rotieren.
• Die Geheimnisse des Modell-API-Schlüssels werden nur bei der Erstellung oder Rotation angezeigt.
• Partner API Inhaber-Tokens werden außerdem nur bei der Generierung/Rotation angezeigt und von Model Gate nur als Hash gespeichert.
• Callback-Signaturgeheimnisse werden nur bei der Generierung/Rotation angezeigt und im Ruhezustand verschlüsselt. Bewahren Sie Ihre Kopie in einem Secret Manager auf.
• Wenn Sie eine API-IP-Zulassungsliste aktivieren, schließen Sie alle ausgehenden NAT-/Ausgangsadressen ein, die Model Gate aufrufen können.