Authenticatie

De productiesleutels van Model Gate beginnen met mg_live_. Dezelfde sleutel werkt voor OpenAI-compatibele en Anthropic-compatibele verzoeken.

OpenAI-compatibele header

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

Gebruik dit formulier voor /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, En /v1/balance.

Antropisch-compatibele header

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

Gebruik dit formulier voor /v1/messages En /v1/messages/count_tokens. Bearer-authenticatie wordt ook geaccepteerd.

Voorbeeld aanvragen

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

Reactie voorbeeld

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

Niet-geverifieerde eindpunten

Alleen servicestatuseindpunten zijn niet geverifieerd:

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

Interactieve browsersessies

Het Model Gate-accountpaneel maakt gebruik van een browsersessie aan de serverzijde die losstaat van de Model API-sleutels. Standaard vervalt een geverifieerde browsersessie daarna 12 uur zonder geverifieerde activiteit of daarna 7 dagen totaal, wat het eerst komt. De browsercookie zelf blijft een sessiecookie, dus het sluiten van de browser kan deze eerder beëindigen, afhankelijk van het browsergedrag.

Wanneer een accountpaneelpagina nog steeds geopend is nadat de authenticatie is verlopen, retourneren AJAX-acties HTTP 401 JSON met code authentication_required en het paneel toont a Sessie verlopen prompt in plaats van de inlogpagina als JSON te behandelen. Een verouderde pagina/CSRF-token retourneert HTTP 419 JSON met code csrf_expired en vraagt ​​om een ​​paginavernieuwing. Mislukte mutaties, inclusief betalingsinitialisatie, worden nooit automatisch herhaald na het inloggen of vernieuwen.

Account- en IP-beveiliging

Het geverifieerde profiel kan TOTP-tweefactorauthenticatie inschakelen met WinAuth of een andere compatibele authenticator. Bedrijfsorganisaties kunnen TOTP voor elk lid eisen; deze vereiste is standaard ingeschakeld voor zakelijke organisaties. Een voltooide tweede-factor-uitdaging wordt geregistreerd tijdens de huidige browsersessie. Gevoelige accountacties zoals het aanmaken/onthullen/roteren van inloggegevens, het wijzigen van het beveiligingsbeleid en het opnieuw genereren van beveiligingsgeheimen vereisen een recent tweedefactorbewijs wanneer TOTP is ingeschakeld; het huidige productvenster is 15 minuten.

Als u TOTP inschakelt, worden er tien eenmalige herstelcodes aangemaakt. Hun volledige waarden worden alleen weergegeven wanneer ze worden gegenereerd; Model Gate slaat alleen hashes op en verbruikt na gebruik atomair een code. Als u herstelcodes opnieuw genereert, worden oudere, ongebruikte codes ongeldig. TOTP-inschrijving vereist het huidige wachtwoord als het account er een heeft, of een recente primaire OAuth/Telegram-authenticatie voor wachtwoordloze accounts. Wachtwoordwijzigingen, TOTP in-/uitschakelen/reset en wijzigingen in het inlogbeveiligingsbeleid trekken verouderde browsersessies in. Beheerders en bedrijfseigenaren/beheerders kunnen de TOTP van een beheerde gebruiker opnieuw instellen wanneer herstel vereist is; die reset ondertekent de browsersessies van het doel, maar trekt de Model API-referenties niet in.

Het profiel presenteert Authenticator-app (TOTP) En Toelatingslijsten voor IP-adressen als afzonderlijke beveiligingscontroles. De initiële authenticator-inschrijving opent een modal en voltooit de installatie/bevestiging met AJAX, terwijl de normale POST-fallback op de server behouden blijft. Login-/API-toelatingslijsten worden in een afzonderlijk modaal bewerkt en opgeslagen met AJAX volgens hetzelfde recente 2FA-step-up-beleid.

Het profiel ondersteunt ook afzonderlijke login- en API IP-toelatingslijsten. Regels zijn exacte IPv4/IPv6-adressen of CIDR-voorvoegsels. Een lege lijst betekent geen beperking. Bedrijfseigenaren/beheerders kunnen daarnaast voor de hele organisatie aanmeldings- en API-toelatingslijsten definiëren. Wanneer zowel persoonlijke als organisatie-API-regels bestaan, moet de verzoekbron met beide overeenkomen. Een verzoek afgewezen door een API IP-beleid retourneert HTTP 403 met code ip_not_allowed waarbij het compatibiliteitsantwoordformaat een foutcode blootlegt.

Voor zakelijke inloggegevens blijft de bedrijfseigenaar de eigenaar van de facturering, terwijl elke inloggegevens een inloggegevensgebruiker (opdrachtgever) registreren. De actieve status van de opdrachtgever, de persoonlijke API IP-toelatingslijst en de RPM/gelijktijdigheidslimieten van gebruikers zijn van toepassing op die sleutel; de bedrijfsbalans/prijzen en het API-IP-beleid van de organisatie blijven bedrijfsgericht. Werknemersreferenties moeten worden toegewezen aan een actieve groep en vereisen een uitvoerbare zakelijke toestemming (admin of developer, waarbij ook de organisatie-eigenaar/beheerdersbevoegdheid wordt geaccepteerd). billing En viewer groepsmachtigingen voeren geen Model API-verkeer uit.

Een groepsbeheerder kan sleutels in die groep beheren, maar kan een geheim dat is uitgegeven aan een andere referentie-principal niet onthullen of rouleren; de directeur zelf en de eigenaar/beheerder van de organisatie hebben toegang tot dat referentiegeheim. Als een eigenaar-principaalgeheim vóór 9.6.2 met werknemers werd gedeeld, roteer het dan en geef speciale werknemers-principaal-referenties uit om betrouwbaar intrekkings-/IP-gedrag per werknemer te verkrijgen.

TOTP beschermt interactief inloggen en gevoelige menselijke accountacties. Wachtwoord-, OAuth- en Telegram-aanmelding gebruiken allemaal hetzelfde tweedefactorbeleid. Herstelcodes kunnen eenmalig worden gebruikt in plaats van TOTP voor aanmelding of opwaardering. Gevoelige Telegram-opdrachten vereisen een tweede factor wanneer TOTP is ingeschreven, en ingediende codes worden geredigeerd uit duurzame Telegram-update-/gespreksopslag. Model-API-verzoeken doen dat wel niet vragen om een ​​TOTP-code of deze valideren: een reeds uitgegeven sleutel wordt geautoriseerd door de sleutelstatus, de status/machtigingen van de inloggegevens, effectieve IP-toelaatlijsten en runtime-/factureringslimieten.

• Bewaar sleutels in omgevingsvariabelen of een geheime manager.
• Leg nooit een sleutel vast aan Git.
• Gebruik voor ieder project of externe gebruiker een aparte sleutel.
• Bevries of draai een gecompromitteerde sleutel onmiddellijk.
• Model-API-sleutelgeheimen worden alleen weergegeven bij het maken of roteren.
• Partner API dragertokens worden ook alleen weergegeven bij generatie/rotatie en worden alleen hash opgeslagen door Model Gate.
• Ondertekeningsgeheimen voor terugbellen worden alleen getoond bij het genereren/rouleren en worden in rust gecodeerd; bewaar uw exemplaar in een geheime manager.
• Als u een API IP-toelatingslijst inschakelt, vermeld dan elk uitgaand NAT/uitgaand adres dat Model Gate kan aanroepen.