Autentificare

Cheile de producție Model Gate încep cu mg_live_. Aceeași cheie funcționează pentru cererile compatibile cu OpenAI și compatibile cu Anthropic.

Antet compatibil cu OpenAI

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

Utilizați acest formular pentru /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, și /v1/balance.

Antet compatibil antropic

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

Utilizați acest formular pentru /v1/messages şi /v1/messages/count_tokens. Este acceptată și autentificarea purtătorului.

Exemplu de solicitare

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

Exemplu de răspuns

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

Puncte finale neautentificate

Numai punctele finale de sănătate ale serviciului sunt neautentificate:

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

Sesiuni interactive de browser

Panoul de cont Model Gate utilizează o sesiune de browser pe partea de server, care este separată de cheile Model API. În mod implicit, o sesiune de browser autentificată expiră după 12 ore fără activitate autentificată sau după 7 zile in total, oricare survine primul. Modulul cookie de browser în sine rămâne un cookie de sesiune, așa că închiderea browserului îl poate încheia mai devreme, în funcție de comportamentul browserului.

Când o pagină din panoul de cont este încă deschisă după expirarea autentificarii, acțiunile AJAX returnează HTTP 401 JSON cu cod authentication_required iar panoul arată a Sesiunea a expirat prompt în loc să trateze pagina de conectare ca JSON. O pagină învechită/un simbol CSRF returnează HTTP 419 JSON cu cod csrf_expired și solicită o reîmprospătare a paginii. Mutațiile eșuate, inclusiv inițializarea plății, nu sunt niciodată redate automat după conectare sau reîmprospătare.

Securitate cont și IP

Profilul autentificat poate activa autentificarea TOTP cu doi factori cu WinAuth sau alt autentificator compatibil. Organizațiile de afaceri pot solicita TOTP pentru fiecare membru; această cerință este activată în mod implicit pentru organizațiile de afaceri. O provocare de al doilea factor finalizată este înregistrată în sesiunea curentă a browserului. Acțiunile sensibile ale contului, cum ar fi crearea/dezvăluirea/rotirea acreditărilor, modificarea politicii de securitate și regenerarea secretelor de securitate necesită o dovadă recentă a factorului al doilea atunci când TOTP este activat; fereastra curentă a produsului este de 15 minute.

Activarea TOTP creează zece coduri de recuperare unice. Valorile lor complete sunt afișate numai atunci când sunt generate; Model Gate stochează doar hash-uri și consumă atomic un cod după utilizare. Regenerarea codurilor de recuperare invalidează codurile mai vechi neutilizate. Înscrierea TOTP necesită parola curentă atunci când contul are una sau o autentificare OAuth/Telegram primară recentă pentru conturile fără parolă. Modificările parolei, activarea/dezactivarea/resetarea TOTP și modificările politicii de conectare-securitate revocă sesiunile de browser învechite. Administratorii și utilizatorii proprietari/administratori de afaceri pot reseta TOTP-ul unui utilizator gestionat atunci când este necesară recuperarea; această resetare deconectează sesiunile de browser ale țintei, dar nu revocă acreditările Model API.

Profilul prezinta Aplicație de autentificare (TOTP) şi Liste permise IP ca controale de securitate separate. Înscrierea inițială a autentificatorului deschide un modal și finalizează configurarea/confirmarea cu AJAX, păstrând în același timp rezerva POST normală pe partea serverului. Listele de permisiuni de conectare/API sunt editate într-un mod separat și salvate cu AJAX după aceeași politică de creștere recentă a 2FA.

Profilul acceptă, de asemenea, liste separate de conectare și IP-uri permise. Regulile sunt adrese IPv4/IPv6 exacte sau prefixe CIDR. O listă goală înseamnă nicio restricție. Proprietarii/administratorii de afaceri pot defini, în plus, listele de autentificare și API la nivel de organizație. Când există atât regulile API personale, cât și cele ale organizației, sursa solicitării trebuie să corespundă ambelor. O solicitare respinsă de o politică IP API returnează HTTP 403 cu cod ip_not_allowed unde formatul de răspuns de compatibilitate expune un cod de eroare.

Pentru acreditările de afaceri, proprietarul companiei rămâne proprietarul facturării, în timp ce fiecare autentificare înregistrează un utilizator de acreditări (principal). Starea activă a principalului, lista personală de IP-uri permise API și limitele RPM/concurență ale utilizatorului se aplică acelei chei; echilibrul/prețurile companiei și politica IP API a organizației rămân la nivelul companiei. Acreditările angajaților trebuie să fie atribuite unui grup activ și necesită o permisiune de afaceri executabilă (admin sau developer, fiind acceptată și autoritatea de proprietar/administrator al organizației). billing şi viewer permisiunile de grup nu execută trafic Model API.

Un administrator de grup poate gestiona cheile din acel grup, dar nu poate dezvălui sau roti un secret emis către alt principal principal de acreditări; directorul însuși și proprietarul/administratorul organizației pot accesa acel secret de acreditări. Dacă un secret proprietar-principal a fost partajat cu angajații înainte de 9.6.2, rotiți-l și emiteți acreditări dedicate angajat-principal pentru a obține un comportament de revocare/IP fiabil pentru fiecare angajat.

TOTP protejează conectarea interactivă și acțiunile sensibile ale contului uman. Conectarea prin parolă, OAuth și Telegram folosesc toate aceeași politică de al doilea factor. Codurile de recuperare pot fi folosite o singură dată în locul TOTP pentru autentificare sau creștere. Comenzile sensibile Telegram necesită un al doilea factor atunci când TOTP este înscris, iar codurile trimise sunt redactate din stocarea durabilă a actualizărilor/conversațiilor Telegram. Solicitările model API fac nu solicitați sau validați un cod TOTP: o cheie deja emisă este autorizată de starea cheii, starea/permisiunile principală a acreditării, listele de IP-uri permise efective și limitele de rulare/facturare.

• Stocați cheile în variabile de mediu sau într-un manager secret.
• Nu comite niciodată o cheie pentru Git.
• Utilizați o cheie separată pentru fiecare proiect sau utilizator extern.
• Înghețați sau rotiți imediat o cheie compromisă.
• Secretele modelului de cheie API sunt afișate numai la creare sau rotație.
• Partner API jetoane purtătoare sunt, de asemenea, afișate numai la generare/rotație și sunt stocate doar pentru hash de Model Gate.
• Secretele de semnare inversă sunt afișate numai la generare/rotire și sunt criptate în repaus; păstrați copia într-un manager secret.
• Dacă activați o listă de permise IP API, includeți fiecare adresă NAT/ieșire de ieșire care poate apela Model Gate.