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 standardmäßige Bestätigungsfenster beträgt 60 Minuten (konfiguriert von TWO_FACTOR_STEP_UP_TTL_SECONDS). Dadurch wird der 30-Sekunden-Zeitraum des Authentifikatorcodes nicht geändert.

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.

Gemeinsame Projektschlüssel in Playground

Entwickler und Administratoren von Geschäftsprojekten können Projektschlüssel in Playground auswählen, selbst wenn ein anderes Mitglied den Schlüssel erstellt hat. Die temporären Browser-Anmeldeinformationen verwenden den angemeldeten Mitarbeiter als Ausführungsidentität: Es gelten dessen aktuelle Gruppenberechtigung, persönliche API-IP-Richtlinie und Benutzerbeschränkungen. Die Schlüssel-/Gruppennutzung und die tatsächliche Abrechnung bleiben dem Unternehmen vorbehalten. Dadurch wird das wiederverwendbare Schlüsselgeheimnis eines anderen Mitglieds nicht preisgegeben und einem Entwickler kein Zugriff auf die Unternehmens-Wallet gewährt. Browsersitzungen können keine verzögerten asynchronen oder Batch-Jobs übermitteln; Verwenden Sie für diese Integrationen einen speziellen, langlebigen Berechtigungsnachweis.

Lesenutzungskontrollen

API-Schlüssel und Schlüsselgruppen werden angezeigt Nutzungslimit, USD gegen rücksetzbare Nutzung, nicht gegen lebenslange Kosten. Sowohl Schlüssel- als auch Gruppenobergrenzen werden durchgesetzt; Null entfernt nur die Decke dieses Objekts. RPM und Parallelität sind separate Grenzwerte für die Anzahl der Anfragen, und das verfügbare Wallet-Guthaben ist eine weitere Voraussetzung.

Der Gruppeneigentümer kann wählen Nutzung zurücksetzen in Gruppen nach der üblichen Sicherheitsbestätigung. Dadurch wird nur der Gruppenzähler gelöscht; Durch das Zurücksetzen des Schlüssels in einer erweiterten API-Schlüsselzeile wird nur dieser Schlüssel gelöscht. Keine der beiden Aktionen führt zu einer Rückerstattung einer Zahlung, zu einer Änderung der Lifetime-Ausgaben oder zu einer Löschung von Anträgen. Das verbleibende Kontingent und die letzte Rücksetzzeit werden neben den Steuerelementen angezeigt.

Die geschätzte Nutzung erbt die Preisbasis und den Multiplikator unabhängig vom Schlüssel zur Gruppe. Es handelt sich nicht um eine weitere Gebühr für den Geldbeutel. Die Abrechnung erfolgt regelmäßig, sodass laufende Anfragen möglicherweise ein Kontingent überschreiten oder nach einem Reset abgeschlossen werden. Hierbei handelt es sich um Zulassungsbeschränkungen, nicht um eine genaue Reservierung für zukünftige Ausgaben.