Autenticação

As chaves de produção do Model Gate começam com mg_live_. A mesma chave funciona para solicitações compatíveis com OpenAI e antrópicas.

Cabeçalho compatível com OpenAI

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

Utilize este formulário para /v1/chat/completions, /v1/responses, /v1/embeddings, /v1/images/generations, /v1/models, e /v1/balance.

Cabeçalho compatível com Antrópico

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

Utilize este formulário para /v1/messages e /v1/messages/count_tokens. A autenticação do portador também é aceita.

Exemplo de solicitação

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

Exemplo de resposta

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

Terminais não autenticados

Apenas os pontos finais de saúde do serviço não são autenticados:

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

Sessões interativas do navegador

O painel da conta do Model Gate usa uma sessão do navegador do lado do servidor separada das chaves da API do modelo. Por padrão, uma sessão de navegador autenticado expira após 12 horas sem atividade autenticada ou depois 7 dias no total, o que ocorrer primeiro. O cookie do navegador em si permanece um cookie de sessão, portanto, fechar o navegador pode encerrá-lo mais cedo, dependendo do comportamento do navegador.

Quando uma página do painel de conta ainda está aberta após a autenticação expirar, as ações AJAX retornam HTTP 401 JSON com código authentication_required e o painel mostra um Sessão expirada prompt em vez de tratar a página de login como JSON. Uma página obsoleta/token CSRF retorna HTTP 419 JSON com código csrf_expired e pede uma atualização da página. Mutações com falha, incluindo inicialização de pagamento, nunca são reproduzidas automaticamente após login ou atualização.

Segurança de conta e IP

O perfil autenticado pode habilitar a autenticação TOTP de dois fatores com WinAuth ou outro autenticador compatível. As organizações empresariais podem exigir TOTP para cada membro; este requisito é habilitado por padrão para organizações empresariais. Um desafio de segundo fator concluído é registrado na sessão atual do navegador. Ações confidenciais da conta, como criação/revelação/rotação de credenciais, alteração da política de segurança e regeneração de segredos de segurança, exigem uma prova recente de segundo fator quando o TOTP está ativado; a janela atual do produto é de 15 minutos.

A ativação do TOTP cria dez códigos de recuperação únicos. Seus valores completos são mostrados somente quando gerados; O Model Gate armazena apenas hashes e consome atomicamente um código após o uso. A regeneração de códigos de recuperação invalida códigos não utilizados mais antigos. A inscrição no TOTP requer a senha atual quando a conta tiver uma, ou uma autenticação primária OAuth/Telegram recente para contas sem senha. Alterações de senha, ativação/desativação/redefinição de TOTP e alterações na política de segurança de login revogam sessões de navegador obsoletas. Administradores e usuários proprietários/administradores de empresas podem redefinir o TOTP de um usuário gerenciado quando a recuperação for necessária; essa redefinição encerra as sessões do navegador de destino, mas não revoga as credenciais da API do modelo.

O perfil apresenta Aplicativo autenticador (TOTP) e Listas de permissões de IP como controles de segurança separados. O registro inicial do autenticador abre um modal e conclui a configuração/confirmação com AJAX, mantendo o fallback POST normal do lado do servidor. As listas de permissões de login/API são editadas em um modal separado e salvas com AJAX após a mesma política de atualização 2FA recente.

O perfil também suporta login separado e listas de permissões de IP de API. As regras são endereços IPv4/IPv6 exatos ou prefixos CIDR. Uma lista vazia significa que não há restrições. Proprietários/administradores de empresas também podem definir listas de permissões de API e login para toda a organização. Quando existirem regras de API pessoais e organizacionais, a origem da solicitação deverá corresponder a ambas. Uma solicitação rejeitada por uma política de IP da API retorna HTTP 403 com código ip_not_allowed onde o formato de resposta de compatibilidade expõe um código de erro.

Para credenciais comerciais, o proprietário da empresa continua sendo o proprietário da cobrança, enquanto cada credencial registra um usuário credencial (principal). O status ativo do principal, a lista de permissões de IP da API pessoal e os limites de RPM/simultaneidade do usuário se aplicam a essa chave; o equilíbrio/preço da empresa e a política de IP da API da organização permanecem no escopo da empresa. As credenciais do funcionário devem ser atribuídas a um grupo ativo e exigem uma permissão comercial executável (admin ou developer, com autoridade de proprietário/administrador da organização também aceita). billing e viewer as permissões de grupo não executam o tráfego da API do modelo.

Um administrador de grupo pode gerenciar chaves nesse grupo, mas não pode revelar ou alternar um segredo emitido para outro principal de credencial; o próprio diretor e o proprietário/administrador da organização podem acessar esse segredo de credencial. Se um segredo proprietário-principal foi compartilhado com funcionários antes da versão 9.6.2, alterne-o e emita credenciais dedicadas de funcionário-principal para obter um comportamento confiável de revogação/IP por funcionário.

O TOTP protege o login interativo e ações confidenciais de contas humanas. O login por senha, OAuth e Telegram usam a mesma política de segundo fator. Os códigos de recuperação podem ser usados ​​uma vez no lugar do TOTP para login ou intensificação. Os comandos sensíveis do Telegram exigem um segundo fator quando o TOTP é registrado, e os códigos enviados são editados do armazenamento durável de atualizações/conversas do Telegram. Solicitações de API de modelo fazem não solicitar ou validar um código TOTP: uma chave já emitida é autorizada pelo estado da chave, status/permissões principais da credencial, listas de permissões de IP efetivas e limites de tempo de execução/faturamento.

• Armazene chaves em variáveis ​​de ambiente ou em um gerenciador de segredos.
• Nunca envie uma chave para o Git.
• Use uma chave separada para cada projeto ou usuário externo.
• Congele ou gire uma chave comprometida imediatamente.
• Os segredos da chave de API do modelo são mostrados apenas na criação ou rotação.
• Partner API tokens de portador também são mostrados apenas na geração/rotação e são armazenados somente como hash pelo Model Gate.
• Os segredos de assinatura de retorno de chamada são mostrados apenas na geração/rotação e são criptografados em repouso; armazene sua cópia em um gerenciador secreto.
• Se você habilitar uma lista de permissões de IP da API, inclua todos os endereços NAT/saída de saída que possam chamar o Model Gate.