Login único (SSO)

O login único (SSO) permite que um provedor de identidade externo e confiável faça o login de usuários no seu Nodaro self-hosted. Você descreve cada provedor na variável EXTERNAL_SSO_PROVIDERS, e a página de login mostra um botão de SSO. A conta em que o usuário entra é um usuário comum da sua instalação: o SSO é só uma forma de iniciar uma sessão. Esta página trata do lado do operador; o protocolo está em Login externo (SSO) para desenvolvedores.

Que tipo de provedor usar

O SSO vem desativado por padrão. Com EXTERNAL_SSO_PROVIDERS sem definir, a página de login não mostra nenhum botão de SSO, GET /v1/sso/providers retorna uma lista vazia, e todas as rotas de provedor respondem 404 unknown_provider.

Configurar os provedores

Defina EXTERNAL_SSO_PROVIDERS como um array JSON, direto no valor ou como @/path/to/providers.json para ler um arquivo.

[
  {
    "id": "librechat",
    "label": "LibreChat",
    "kind": "assertion",
    "secret": "a-dedicated-32+char-hmac-key-not-the-idp-session-secret",
    "audience": "nodaro",
    "claimMap": { "email": "email", "emailVerified": "email_verified", "subject": "sub" },
    "initiateUrl": "https://chat.example.com/oauth/nodaro",
    "maxLifetimeSeconds": 300
  },
  {
    "id": "keycloak",
    "label": "Acme (Keycloak)",
    "kind": "oidc",
    "supabaseProvider": "keycloak"
  }
]

Um valor malformado interrompe a inicialização. Um erro de digitação em uma entrada que guarda um segredo nunca pode descartar um provedor em silêncio, o que pareceria uma falha do SSO com 404, nem deixar o login configurado pela metade.

Na stack do Compose, adicione EXTERNAL_SSO_PROVIDERS e EXTERNAL_SSO_LINK_EXISTING em environment: do serviço nodaro, porque o arquivo do Compose não as repassa do .env. Para usar um arquivo, monte-o no contêiner e informe o caminho dele dentro do contêiner.

Campos do provedor

Só id, label e kind são publicados, por GET /v1/sso/providers. O segredo nunca sai do servidor.

O que o Nodaro verifica em uma asserção

O servidor de identidade de um provedor assertion assina um JWT e envia o navegador para GET /v1/sso/<id>?assertion=<jwt>. O Nodaro só aceita a asserção quando todas estas condições são cumpridas:

• Ela é assinada com HS256 e com o secret do provedor.
• aud é igual ao audience do provedor.
• exp está presente e não está no passado, com 5 segundos de tolerância, e o tempo de vida está dentro de maxLifetimeSeconds.
• jti está presente e nunca foi usado. Cada asserção funciona uma vez.
• A claim de e-mail está presente. A claim de e-mail verificado precisa ser true para criar ou vincular uma conta.

Uma verificação que falha responde 401. A rota aceita 20 requisições a cada 60 segundos de um mesmo endereço IP e, acima disso, responde 429. O contrato completo, os códigos de erro e o fluxo de redirecionamento estão em Login externo (SSO) para desenvolvedores.

Como as contas são vinculadas

Quando uma asserção passa, o Nodaro encontra ou cria o usuário correspondente. As regras garantem que uma asserção nunca possa assumir uma conta existente só porque ela tem o mesmo endereço de e-mail.

O padrão de EXTERNAL_SSO_LINK_EXISTING é false, o que protege contra a tomada de contas. Só true ou 1, com qualquer combinação de maiúsculas e minúsculas, ativam a vinculação. Ative-a só quando você confiar nas claims de e-mail verificado dos seus provedores a ponto de associá-las a contas existentes.

account_exists e email_unverified usam o mesmo texto para todas as contas, então o formulário de login não pode ser usado para descobrir quais endereços existem. O log do servidor registra qual conta foi o alvo.

O botão de login

A página de login mostra um botão de SSO quando pelo menos um provedor está configurado.

• Um provedor: o botão mostra Entrar com SSO, ou o auth.ssoLabel do perfil de superfície.
• Vários provedores: cada botão mostra o label do provedor dele, a menos que o perfil de superfície defina auth.ssoLabel.

Depois do login, o usuário chega a /projects. O provedor pode enviar outra página adicionando &next=<path> ao redirecionar de volta. O Nodaro só respeita esse valor quando ele é um caminho relativo na mesma origem, começando com /, mas não com //. Qualquer outro valor leva a /projects. Nos hosts listados em CORS_ORIGIN, o redirecionamento para a página de destino continua relativo, no host pelo qual o usuário chegou.

Permitir o login só por SSO

Na Business edition, o perfil de superfície pode remover os outros métodos de login:

NODARO_SURFACE_PROFILE={"auth":{"methods":["sso"],"ssoLabel":"Sign in with Acme"}}

Uma lista que cita só sso também ativa uma regra no servidor: toda conta logada precisa ter sido criada ou vinculada pelo SSO. Qualquer outra sessão é recusada na primeira chamada à API com 403 sso_required, então uma conta registrada diretamente no serviço de login não pode usar a instalação. Adicionar email à lista desativa a regra. Veja Edições e perfis de superfície.

Resumo de segurança

• Um segredo dedicado por provedor, diferente do segredo de sessão do próprio provedor.
• Asserções de uso único, com um tempo de vida curto, imposto pelo servidor.
• Só redirecionamentos na mesma origem depois do login.
• Nenhum segredo sai do servidor. As asserções e os tokens de uso único são removidos dos logs de requisições.
• Limites de taxa na rota de troca, por endereço IP.
• Sessões comuns. Depois da troca, o usuário é um usuário normal, sem nenhuma credencial especial.