Login único (SSO) na plataforma de atendimento: guia de OpenID Connect para equipes de suporte

O login único (SSO) em uma plataforma de atendimento ao cliente significa que seus atendentes entram com a conta da empresa no provedor de identidade, como Microsoft Entra ID, Okta, Keycloak, AD FS ou Google Workspace, em vez de usar uma senha separada. O padrão por trás disso é o OpenID Connect (OIDC). Em uma instalação on-premise do MonoChat, você configura uma vez para a instalação inteira, limita aos domínios de e-mail da sua empresa e pode torná-lo a única forma de entrar.

As equipes de suporte têm um motivo especial para se importar. A conta de um atendente abre todas as conversas de WhatsApp, Instagram e Messenger que ele pode ver: nomes, telefones, dados de pedidos e, às vezes, dúvidas sobre saúde ou pagamento. Essa conta deve seguir as mesmas regras das demais contas da empresa e deve parar de funcionar no dia em que a pessoa sair.

Por que o login importa para uma equipe de suporte

Credenciais roubadas ou mal utilizadas continuam sendo a porta de entrada mais comum para os ataques a empresas. O Relatório de Investigações de Violação de Dados 2025 da Verizon, que analisou 12.195 violações confirmadas, mostrou que o abuso de credenciais (22%) e a exploração de vulnerabilidades (20%) foram os principais vetores iniciais de ataque.

Uma plataforma de mensagens com senhas próprias adiciona mais um conjunto de credenciais para cada atendente: mais uma senha para reaproveitar, mais uma conta para esquecer de desativar quando alguém sai, mais um login que as suas regras de autenticação multifator e de acesso condicional não cobrem. Com o SSO, a plataforma nunca vê a senha. O seu provedor de identidade a verifica, aplica o MFA e as políticas de acesso e informa à plataforma quem entrou.

Como funciona o login com OpenID Connect

O OpenID Connect é uma camada de identidade sobre o OAuth 2.0. O fluxo que o MonoChat usa é o de código de autorização (authorization code flow):

1. O atendente clica no botão de SSO na página de login. O MonoChat abre a página de login do seu provedor de identidade em uma janela pop-up.
2. O atendente entra ali, com o seu MFA e as suas políticas.
3. O provedor de identidade devolve o navegador ao MonoChat com um código de uso único.
4. O servidor do MonoChat troca o código por um token de ID, de servidor para servidor. Os tokens nunca passam pelo navegador.
5. O MonoChat verifica o token de ID e faz o login do atendente.

O token de ID é, nas palavras da especificação do OpenID Connect, “a security token that contains Claims about the Authentication of an End-User” (um token de segurança que contém declarações sobre a autenticação de um usuário final). O MonoChat só o aceita quando:

• ele é assinado por uma das chaves do seu provedor de identidade, lidas do documento de descoberta (<issuer>/.well-known/openid-configuration) a cada login;
• o emissor (iss) é o seu emissor, a audiência (aud) é o client ID do MonoChat e a expiração (exp) ainda não passou;
• ele traz o nonce que o MonoChat enviou na solicitação, o que vincula o token a este login e impede reutilizações;
• ele contém o endereço de e-mail da pessoa, e o provedor não informa que esse endereço não foi verificado.

A solicitação também usa PKCE (S256) e um valor state, e uma solicitação de login vale por 10 minutos e só pode ser usada uma vez.

Decida estas cinco coisas antes de ativar o SSO

Decisão	Opções	O que sugerimos para uma equipe de suporte
Quem pode entrar	Qualquer domínio, ou apenas os domínios de e-mail da sua empresa	Limite aos seus domínios
O que acontece no primeiro login	Criar a conta, ou aceitar só pessoas convidadas	Crie as contas se o seu provedor de identidade já controla quem trabalha na empresa
Contas existentes	Vincular o SSO no primeiro login quando o e-mail está verificado, ou depois de um login com senha	Depende de o seu provedor enviar email_verified
Outros métodos de login	Manter senhas e login social, ou somente SSO	Somente SSO, quando todos tiverem vinculado o SSO
Quem pode abrir novos workspaces	Qualquer pessoa com conta, ou só quem tem o perfil adequado	Desative a criação livre de workspaces em uma instalação corporativa

Anote essas decisões antes de alterar qualquer configuração. São as perguntas que o seu time de segurança vai fazer, e as respostas definem quais configurações você precisa.

Configure o SSO em uma instalação on-premise do MonoChat

O SSO é configurado para a instalação inteira nas configurações do servidor, e não por workspace. A referência completa está na página de login único da central de ajuda; aqui vai a versão resumida.

1. Registre o MonoChat no seu provedor de identidade

Crie um aplicativo web com um client secret e informe:

• a URI de redirecionamento https://<seu domínio do MonoChat>/api/oauth/oidc/redirect;
• o grant de código de autorização;
• os escopos openid email profile;
• a autenticação do cliente com o secret enviado como HTTP Basic (client_secret_basic).

Garanta que o token de ID inclua a declaração (claim) email e anote o client ID, o client secret e o emissor.

2. Copie o emissor exatamente

O emissor é o valor de issuer no documento de descoberta do seu provedor. Formatos típicos:

Provedor de identidade	Emissor
Microsoft Entra ID	https://login.microsoftonline.com/<tenant id>/v2.0
Okta	https://<seu domínio Okta>/oauth2/default ou https://<seu domínio Okta>
Keycloak	https://<seu host Keycloak>/realms/<realm>
AD FS 2016 ou posterior	https://<seu host AD FS>/adfs
Google Workspace	https://accounts.google.com

Abra <issuer>/.well-known/openid-configuration no navegador e copie o valor caractere por caractere, inclusive a barra final, se houver. O MonoChat recusa todos os logins quando os dois valores diferem, o que é o motivo mais comum de o primeiro teste falhar.

3. Adicione as configurações e reinicie

A parte pública (emissor, client ID, caminho de redirecionamento, escopos e o texto do botão) fica em public.oauth.oidc; o client secret fica em oauth.oidc e permanece no servidor. Duas opções ali carregam as decisões da tabela acima:

• autoCreateAccounts: true cria a conta no MonoChat no primeiro login por SSO da pessoa, mesmo quando o cadastro é somente por convite;
• allowedEmailDomains: ["suaempresa.com.br"] recusa todos os endereços de outro domínio. No Google Workspace, o MonoChat verifica o domínio do Workspace da conta (a declaração hd) em vez do endereço de e-mail, porque uma conta pessoal do Google pode usar um endereço de qualquer domínio.

O botão exibe “Entrar com SSO” no idioma de cada pessoa, ou o texto que você definir, como “Entrar com Northwind SSO”.

4. Torne o SSO o único método, com segurança

Quando todos tiverem vinculado o SSO, defina os métodos de login permitidos (public.auth.methods) como ["oidc"]. A página de login passa a mostrar apenas o botão de SSO, e o servidor recusa o login por senha e por conta social. Os superusuários root ainda podem entrar com a senha em /auth/signin?fallback=1, de modo que um provedor de identidade fora do ar nunca tranca a instalação. Para impedir que novas contas de SSO abram workspaces próprios, defina public.disableTenantCreation como true.

5. Teste quatro logins

1. Uma pessoa com conta: o pop-up fecha e ela já está dentro.
2. Uma pessoa sem conta: a conta é criada, ou o acesso é recusado se você não ativou a criação de contas.
3. Uma pessoa de outro domínio: recusada, se você limitou os domínios.
4. Um login por senha com o modo somente SSO ativo: recusado, enquanto o acesso alternativo do root continua funcionando.

Atendentes que já existem: como as contas são vinculadas

A maioria das equipes ativa o SSO com atendentes que já têm conta no MonoChat. O MonoChat vincula o SSO a uma conta existente com o mesmo endereço de e-mail de duas formas:

• Automaticamente, no primeiro login por SSO, quando a instalação permite a mesclagem e o token de ID informa que o endereço está verificado (email_verified: true).
• Após um login com senha, em todos os outros casos: o MonoChat pede que a pessoa entre uma vez com a senha e vincula o SSO nesse momento. Aceitar um convite para um workspace também faz a vinculação.

Microsoft Entra ID e AD FS não enviam email_verified. Com eles, mantenha o login por senha permitido até que todos tenham vinculado o SSO, ou convide as pessoas novamente, antes de passar para somente SSO.

SSO é a identidade; os perfis de acesso são o acesso

Entrar dá à pessoa uma conta, não acesso às suas conversas. Uma conta do MonoChat pode pertencer a vários workspaces, e as pessoas entram antes de escolher um. A pessoa só vê um workspace depois que ele a convida e define um perfil de acesso, e é esse perfil que decide a quais canais, conversas e configurações ela tem acesso. Veja funções e permissões na caixa de entrada da equipe para saber como configurá-los.

É essa separação que um auditor vai querer ver:

• Entrada: o provedor de identidade cria a pessoa; um administrador do workspace a convida e escolhe o perfil.
• Mudança de área: altere o perfil ou o grupo de trabalho no MonoChat; o login não muda.
• Saída: desative a pessoa no provedor de identidade e remova-a do workspace no MonoChat.

Limites para planejar

• O aplicativo móvel. O aplicativo MonoChat para Android e iOS ainda não oferece SSO. Se o SSO for o único método de login, os atendentes não conseguem entrar no celular; mantenha outro método para quem usa o aplicativo móvel ou planeje turnos somente no computador.
• Logout. Sair do MonoChat não desconecta a pessoa do provedor de identidade, e sair de lá ainda não a desconecta do MonoChat. Desativar quem saiu no provedor de identidade impede novos logins; remova a pessoa também do workspace.
• Rede. Os navegadores das pessoas precisam alcançar /api/oauth/oidc/authorize e o caminho de redirecionamento, e o servidor do MonoChat precisa alcançar, por HTTPS, o documento de descoberta, o endpoint de token e o conjunto de chaves do seu provedor. Se você também restringe a instalação por IP, considere esses caminhos.

Onde o SSO se encaixa no MonoChat

O SSO é configurado nas configurações do servidor de uma instalação inteira, então hoje ele pertence ao MonoChat on-premise: a opção Enterprise para equipes que rodam a plataforma nos próprios servidores, com o seu próprio LLM e banco de dados vetorial. A página Enterprise explica a opção on-premise, e a página de segurança trata do controle de acesso por perfis, do isolamento entre workspaces e das certificações. Para o lado dos dados em uma implantação de IA, veja o checklist de privacidade para chatbots de IA.

Para experimentar o produto antes, o plano Basic gratuito em app.monochat.ai oferece um atendente e um canal.

Fontes

• OpenID Connect Core 1.0, OpenID Foundation, acessado em 4 nov 2026
• Anúncio do Relatório de Investigações de Violação de Dados 2025 da Verizon, acessado em 4 nov 2026
• Central de ajuda do MonoChat: Login único para uma instalação on-premise, acessado em 4 nov 2026
• Changelog do MonoChat 3.8.43, 2 nov 2026