Autenticazione

Le chiavi di produzione di Model Gate iniziano con mg_live_. La stessa chiave funziona per le richieste compatibili con OpenAI e compatibili con Anthropic.

Intestazione compatibile con OpenAI

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

Utilizza questo modulo per /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, E /v1/balance.

Intestazione compatibile con l'ambiente antropico

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

Utilizza questo modulo per /v1/messages E /v1/messages/count_tokens. È accettata anche l'autenticazione del portatore.

Richiedi esempio

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

Esempio di risposta

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

Endpoint non autenticati

Solo gli endpoint di integrità del servizio non sono autenticati:

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

Sessioni interattive del browser

Il pannello dell'account Model Gate utilizza una sessione del browser lato server separata dalle chiavi API del modello. Per impostazione predefinita, una sessione del browser autenticato scade dopo 12 ore senza attività autenticata o dopo 7 giorni in totale, a seconda di quale evento si verifichi per primo. Il cookie del browser stesso rimane un cookie di sessione, pertanto la chiusura del browser potrebbe terminarlo prima a seconda del comportamento del browser.

Quando una pagina del pannello dell'account è ancora aperta dopo la scadenza dell'autenticazione, le azioni AJAX restituiscono HTTP 401 JSON con codice authentication_required e il pannello mostra a Sessione scaduta prompt invece di trattare la pagina di accesso come JSON. Una pagina/token CSRF non aggiornato restituisce HTTP 419 JSON con codice csrf_expired e richiede un aggiornamento della pagina. Le mutazioni non riuscite, inclusa l'inizializzazione del pagamento, non vengono mai riprodotte automaticamente dopo l'accesso o l'aggiornamento.

Sicurezza dell'account e dell'IP

Il profilo autenticato può abilitare l'autenticazione a due fattori TOTP con WinAuth o un altro autenticatore compatibile. Le organizzazioni imprenditoriali possono richiedere TOTP per ogni membro; questo requisito è abilitato per impostazione predefinita per le organizzazioni aziendali. Una sfida di secondo fattore completata viene registrata nella sessione corrente del browser. Le azioni sensibili dell'account come la creazione/rivelazione/rotazione delle credenziali, la modifica della policy di sicurezza e la rigenerazione dei segreti di sicurezza richiedono una prova recente di secondo fattore quando TOTP è abilitato; la finestra attuale del prodotto è di 15 minuti.

L'abilitazione di TOTP crea dieci codici di ripristino una tantum. I loro valori completi vengono mostrati solo quando vengono generati; Model Gate memorizza solo hash e consuma atomicamente un codice dopo l'uso. La rigenerazione dei codici di ripristino invalida i codici precedenti non utilizzati. La registrazione TOTP richiede la password corrente quando l'account ne ha una o una recente autenticazione primaria OAuth/Telegram per gli account senza password. Le modifiche alla password, l'attivazione/disattivazione/reimpostazione del TOTP e le modifiche ai criteri di sicurezza dell'accesso revocano le sessioni del browser obsolete. Gli amministratori e gli utenti titolari/amministratori dell'azienda possono reimpostare il TOTP di un utente gestito quando è necessario il ripristino; tale ripristino disconnette le sessioni del browser di destinazione ma non revoca le credenziali dell'API del modello.

Il profilo presenta App di autenticazione (TOTP) E Liste consentite IP come controlli di sicurezza separati. La registrazione iniziale dell'autenticatore apre una finestra modale e completa la configurazione/conferma con AJAX mantenendo il normale fallback POST lato server. Le liste consentite di accesso/API vengono modificate in una modalità separata e salvate con AJAX dopo la stessa recente policy di step-up 2FA.

Il profilo supporta anche accessi separati e liste consentite IP API. Le regole sono indirizzi IPv4/IPv6 esatti o prefissi CIDR. Un elenco vuoto significa nessuna restrizione. I proprietari/amministratori delle aziende possono inoltre definire elenchi consentiti di accesso e API a livello di organizzazione. Quando esistono sia regole API personali che dell'organizzazione, l'origine della richiesta deve corrispondere ad entrambe. Una richiesta rifiutata da una policy IP API restituisce HTTP 403 con codice ip_not_allowed dove il formato della risposta di compatibilità espone un codice di errore.

Per le credenziali aziendali, il proprietario dell'azienda rimane il proprietario della fatturazione mentre ogni credenziale registra un utente credenziale (principale). A tale chiave si applicano lo stato attivo dell'entità, la lista consentita degli IP API personali e i limiti RPM/concorrenza degli utenti; il saldo aziendale/i prezzi e la politica IP dell'API dell'organizzazione rimangono nell'ambito aziendale. Le credenziali del dipendente devono essere assegnate a un gruppo attivo e richiedono un'autorizzazione aziendale eseguibile (admin O developer, con l'autorizzazione accettata anche del proprietario dell'organizzazione/amministratore). billing E viewer le autorizzazioni del gruppo non eseguono il traffico API del modello.

Un amministratore di gruppo può gestire le chiavi in ​​quel gruppo, ma non può rivelare o ruotare un segreto rilasciato a un'altra entità credenziale; l'entità stessa e il proprietario/amministratore dell'organizzazione possono accedere a tale segreto della credenziale. Se un segreto proprietario-preside è stato condiviso con i dipendenti prima della versione 9.6.2, ruotarlo ed emettere credenziali dipendente-preside dedicate per ottenere un comportamento affidabile di revoca/IP per dipendente.

TOTP protegge l'accesso interattivo e le azioni sensibili degli account umani. Password, OAuth e accesso a Telegram utilizzano tutti la stessa politica del secondo fattore. I codici di ripristino possono essere utilizzati una volta al posto del TOTP per l'accesso o l'avanzamento. I comandi sensibili di Telegram richiedono un secondo fattore quando TOTP è registrato e i codici inviati vengono oscurati dall'archivio durevole di aggiornamenti/conversazioni di Telegram. Le richieste API del modello lo fanno non richiedere o convalidare un codice TOTP: una chiave già emessa è autorizzata dallo stato della chiave, dallo stato/autorizzazioni dell'entità credenziale, dalle liste consentite IP effettive e dai limiti di runtime/fatturazione.

• Memorizza le chiavi nelle variabili di ambiente o in un gestore segreto.
• Non impegnare mai una chiave su Git.
• Utilizzare una chiave separata per ciascun progetto o utente esterno.
• Congelare o ruotare immediatamente una chiave compromessa.
• I segreti della chiave API del modello vengono visualizzati solo al momento della creazione o della rotazione.
• Anche Partner API token al portatore vengono visualizzati solo durante la generazione/rotazione e vengono archiviati solo hash da Model Gate.
• I segreti di firma della richiamata vengono visualizzati solo durante la generazione/rotazione e sono crittografati quando sono inattivi; archivia la tua copia in un gestore segreto.
• Se abiliti una lista consentita IP API, includi tutti gli indirizzi NAT/in uscita in uscita che potrebbero chiamare Model Gate.