B2BB2B LLM

Uwierzytelnianie

Uwierzytelnij wszystkie żądania API Model Gate za pomocą jednego produkcyjnego klucza API.

Uwierzytelnianie

Klucze produkcyjne Model Gate zaczynają się od mg_live_. Ten sam klucz działa w przypadku żądań zgodnych z OpenAI i Anthropic.

Nagłówek zgodny z OpenAI

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

Użyj tego formularza do /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, I /v1/balance.

Nagłówek zgodny z antropią

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

Użyj tego formularza do /v1/messages I /v1/messages/count_tokens. Akceptowane jest również uwierzytelnianie na okaziciela.

Poproś o przykład

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

Przykład odpowiedzi

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

Nieuwierzytelnione punkty końcowe

Tylko punkty końcowe kondycji usługi są nieuwierzytelnione:

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

Interaktywne sesje przeglądarki

Panel konta Model Gate korzysta z sesji przeglądarki po stronie serwera, która jest oddzielna od kluczy Model API. Domyślnie uwierzytelniona sesja przeglądarki wygasa po 12 godzin bez uwierzytelnionej aktywności lub po Łącznie 7 dni, w zależności od tego, co nastąpi wcześniej. Sam plik cookie przeglądarki pozostaje plikiem sesyjnym, więc zamknięcie przeglądarki może zakończyć go wcześniej, w zależności od zachowania przeglądarki.

Gdy strona panelu konta jest nadal otwarta po wygaśnięciu uwierzytelnienia, akcje AJAX zwracają HTTP 401 JSON z kodem authentication_required i panel pokazuje a Sesja wygasła monit zamiast traktować stronę logowania jako JSON. Nieaktualna strona/token CSRF zwraca HTTP 419 JSON z kodem csrf_expired i prosi o odświeżenie strony. Nieudane mutacje, w tym inicjalizacja płatności, nigdy nie są automatycznie odtwarzane po zalogowaniu lub odświeżeniu.

Bezpieczeństwo konta i IP

Uwierzytelniony profil może włączyć uwierzytelnianie dwuskładnikowe TOTP za pomocą WinAuth lub innego kompatybilnego uwierzytelniacza. Organizacje biznesowe mogą wymagać TOTP dla każdego członka; to wymaganie jest domyślnie włączone dla organizacji biznesowych. Ukończone wyzwanie drugiego czynnika jest rejestrowane w bieżącej sesji przeglądarki. Wrażliwe działania na koncie, takie jak tworzenie/ujawnianie/rotacja poświadczeń, zmiana polityki bezpieczeństwa i ponowne generowanie sekretów bezpieczeństwa wymagają aktualnego dowodu drugiego czynnika, gdy włączony jest TOTP; aktualne okno produktu wynosi 15 minut.

Włączenie TOTP tworzy dziesięć jednorazowych kodów odzyskiwania. Ich pełne wartości są wyświetlane dopiero po wygenerowaniu; Model Gate przechowuje tylko skróty i atomowo zużywa kod po użyciu. Regeneracja kodów odzyskiwania unieważnia starsze, nieużywane kody. Rejestracja w TOTP wymaga bieżącego hasła, jeśli konto je posiada, lub ostatniego podstawowego uwierzytelnienia OAuth/Telegram w przypadku kont bez hasła. Zmiany hasła, włączenie/wyłączenie/resetowanie TOTP i zmiany zasad bezpieczeństwa logowania powodują unieważnienie nieaktualnych sesji przeglądarki. Administratorzy i właściciele firm/użytkownicy administratorzy mogą zresetować TOTP zarządzanego użytkownika, gdy wymagane jest odzyskanie danych; ten reset wylogowuje sesje przeglądarki docelowej, ale nie unieważnia poświadczeń API modelu.

Profil prezentuje Aplikacja uwierzytelniająca (TOTP) I Listy dozwolonych adresów IP jako oddzielne kontrole bezpieczeństwa. Początkowa rejestracja modułu uwierzytelniającego otwiera moduł i kończy konfigurację/potwierdzenie za pomocą AJAX, zachowując normalny tryb awaryjny POST po stronie serwera. Listy dozwolonych logowania/API są edytowane w osobnym trybie i zapisywane za pomocą AJAX zgodnie z tą samą polityką dotyczącą niedawnego zwiększania poziomu 2FA.

Profil obsługuje także oddzielne listy dozwolonych logowania i adresów IP API. Reguły to dokładne adresy IPv4/IPv6 lub prefiksy CIDR. Pusta lista oznacza brak ograniczeń. Właściciele/administratorzy firm mogą dodatkowo zdefiniować listy dozwolonych loginów i interfejsów API dla całej organizacji. Jeśli istnieją reguły interfejsu API zarówno osobiste, jak i organizacyjne, źródło żądania musi pasować do obu. Żądanie odrzucone przez zasady IP interfejsu API zwraca protokół HTTP 403 z kodem ip_not_allowed gdzie format odpowiedzi zgodności ujawnia kod błędu.

W przypadku poświadczeń biznesowych właściciel firmy pozostaje właścicielem rozliczeń, podczas gdy każde poświadczenie rejestruje użytkownika poświadczeń (głównego). Do tego klucza mają zastosowanie status aktywnego podmiotu zabezpieczeń, lista dozwolonych osobistych adresów IP API oraz limity RPM/współbieżności użytkownika; polityka dotycząca salda/cennika firmy i organizacji dotyczących własności intelektualnej API organizacji pozostaje ograniczona do firmy. Poświadczenia pracownika muszą być przypisane do aktywnej grupy i wymagać wykonywalnego pozwolenia biznesowego (admin Lub developer, z akceptowanymi uprawnieniami właściciela/administratora organizacji). billing I viewer uprawnienia grupowe nie wykonują ruchu Model API.

Administrator grupy może zarządzać kluczami w tej grupie, ale nie może ujawniać ani zmieniać sekretu wydanego innemu podmiotowi uwierzytelniającemu; sam podmiot główny oraz właściciel/administrator organizacji mogą uzyskać dostęp do tego sekretu poświadczeń. Jeśli tajemnica właściciela-głównego została udostępniona pracownikom przed wersją 9.6.2, należy ją zmienić i wydać dedykowane dane uwierzytelniające pracownika-głównego, aby uzyskać niezawodne zachowanie w zakresie unieważnienia/IP dla każdego pracownika.

TOTP chroni interaktywne logowanie i wrażliwe działania na kontach ludzkich. Logowanie przy użyciu hasła, protokołu OAuth i telegramu korzysta z tej samej zasady drugiego czynnika. Kody odzyskiwania można wykorzystać jednorazowo zamiast TOTP w celu zalogowania się lub przejścia na wyższy poziom. Wrażliwe polecenia Telegramu wymagają drugiego czynnika, gdy zarejestrowany jest TOTP, a przesłane kody są redagowane z trwałego magazynu aktualizacji/rozmów Telegramu. Żądania modelu API tak nie monit o podanie lub potwierdzenie kodu TOTP: już wydany klucz jest autoryzowany przez stan klucza, status/uprawnienia głównego źródła danych, efektywne listy dozwolonych adresów IP oraz limity czasu działania/rozliczeń.

  • Przechowuj klucze w zmiennych środowiskowych lub w tajnym menedżerze.
  • Nigdy nie udostępniaj klucza Gitowi.
  • Użyj osobnego klucza dla każdego projektu lub użytkownika zewnętrznego.
  • Natychmiast zamroź lub obróć skompromitowany klucz.
  • Wpisy tajne klucza API modelu są wyświetlane tylko podczas tworzenia lub rotacji.
  • Tokeny okaziciela Partner API są również wyświetlane tylko podczas generowania/rotacji i są przechowywane wyłącznie w formie skrótu przez Model Gate.
  • Sekrety podpisywania wywołania zwrotnego są wyświetlane tylko podczas generowania/rotacji i są szyfrowane w stanie spoczynku; przechowuj swoją kopię w tajnym menedżerze.
  • Jeśli włączysz listę dozwolonych adresów IP interfejsu API, uwzględnij każdy wychodzący adres NAT/wyjściowy, który może wywoływać bramę modelu.