O Signater passou a oferecer Single Sign-On. O time da sua empresa entra na plataforma pelo provedor de identidade que ela já usa, sem senha do Signater, e o administrador da conta controla quais domínios entram por esse caminho.
O recurso está no ar, usa o protocolo OpenID Connect (OIDC) e foi validado com Microsoft Entra ID, Okta, Google Workspace, Auth0 e Keycloak. Faz parte do plano Enterprise, sem contratação de módulo à parte e sem cobrança por usuário autenticado.
O que é Single Sign-On
Single Sign-On é entrar em vários sistemas com uma credencial só, a mesma que a empresa já emite para o funcionário. Funciona como o crachá do prédio, que abre as portas do andar sem que cada sala peça uma chave diferente.
O provedor de identidade é o sistema onde a empresa guarda essa credencial e as regras de acesso: quem existe, quem foi desligado, quem precisa de segundo fator. Microsoft Entra ID, Okta e Google Workspace são os mais comuns nesse posto. Com o SSO ligado, o Signater passa a perguntar a esse provedor quem é a pessoa, em vez de manter uma senha própria.
A ligação entre os dois usa OpenID Connect, o protocolo que os provedores corporativos publicam para esse tipo de integração (OpenID Foundation). Quem administra a conta não precisa conhecer o protocolo, e sim copiar três campos que o provedor entrega prontos.
O fluxo de entrada
Na tela de entrada do Signater, ao lado do login com Google, aparece o botão SSO. O caminho tem quatro passos:
- A pessoa clica em SSO e digita o e-mail de trabalho.
- O Signater identifica o domínio do e-mail e localiza a conexão da empresa.
- O provedor de identidade assume: pede a senha corporativa e o segundo fator que a política da empresa exigir.
- A pessoa volta para o Signater já autenticada, sem nenhuma senha do Signater no meio do caminho.
Se o domínio digitado não tiver SSO habilitado, a tela avisa e oferece os outros métodos de entrada.
As três chaves da conexão
A configuração gira em torno de três chaves independentes, e cada uma responde a uma pergunta diferente.
Habilitar SSO
Liga a conexão e faz o botão aparecer. Sozinha, ela não obriga ninguém: quem preferir continua entrando por senha.
Exigir SSO
Tira a senha de circulação. Com essa chave ligada, o Signater recusa senha e login com Google para qualquer pessoa dos domínios verificados.
O dono da conta e os administradores continuam entrando por senha, e essa exceção é proposital. Ela é a válvula de emergência para o dia em que o provedor de identidade cair ou alguém errar a configuração do aplicativo: sem essa saída, um erro de digitação trancaria a empresa inteira para fora da própria conta.
A regra também alcança quem já estava dentro. Uma sessão aberta por senha antes de você exigir SSO não se renova sozinha para sempre: na renovação das credenciais, o Signater aplica a mesma regra e devolve a pessoa para a tela de entrada, agora pelo SSO. Se a conta deixar de incluir o recurso, a regra sai de cena sozinha e ninguém fica trancado do lado de fora.
A ordem de implantação usa essas duas chaves em momentos diferentes: ligue a conexão sem exigir SSO, peça para algumas pessoas entrarem pelo botão e conferir que caem no lugar certo, e só depois ligue a exigência para o restante da empresa.
Criar usuários automaticamente
Define o que acontece no primeiro acesso de alguém que ainda não está na conta.
Ligada, a pessoa é criada e vinculada à conta no primeiro login pelo SSO. Um time de vinte pessoas dispensa vinte convites: o administrador libera o aplicativo no portal da empresa e cada um entra no dia em que precisar. Desligada, o SSO continua autenticando, mas só passa quem já é membro ativo da conta, com convite nominal antes do primeiro acesso.
Custo por pessoa não entra nessa decisão. Todos os planos pagos do Signater incluem usuários ilimitados, então liberar o departamento inteiro não mexe na fatura.
Verificação de domínio por DNS
O Signater só aceita um e-mail no SSO quando o domínio dele está verificado para aquela conexão. A prova é um registro DNS.
Você adiciona suaempresa.com.br na tela de Domínios de entrada permitidos, o Signater devolve um registro TXT no formato signater-sso-verification= seguido de um token, e você publica esse registro na zona do domínio. Enquanto o registro não aparecer na consulta, o domínio fica pendente e ninguém entra por ele.
Sem essa exigência, uma conta qualquer reivindicaria gmail.com e passaria a interceptar o login de quem usa esse domínio. Um domínio verificado também fica travado: enquanto uma conexão o mantém, nenhuma outra conta consegue verificar o mesmo domínio. O recurso está listado junto do resto das proteções da conta na página de segurança.
Como configurar
A tela fica em Configurações → Conta → Single Sign-On, visível para administradores.
O primeiro passo acontece do outro lado, no provedor: o administrador registra ali um aplicativo novo. A Redirect URI que o provedor pede já está na tela do Signater antes de existir conexão salva, e é a mesma para qualquer provedor e qualquer domínio.
De volta ao Signater, três campos vêm do provedor:
- Authority URL: o endereço do seu ambiente no provedor, aquilo que identifica a sua empresa dentro dele. No Entra ID, o endereço carrega o identificador do seu tenant.
- Client ID: o nome de registro do aplicativo que você acabou de criar. É público e diz ao provedor quem está pedindo a autenticação.
- Client Secret: a senha desse aplicativo. O Signater grava cifrado e nunca devolve o valor na tela, nem para você; para trocar, digite o novo por cima do antigo.
O papel padrão completa a configuração. Ele define com que permissão a pessoa nasce na conta no primeiro acesso, entre administrador e usuário comum, e quem precisar de mais acesso depois é promovido na tela de usuários. Feito isso, cadastre os domínios, verifique o TXT e ligue a conexão. Cada mudança nessa tela fica registrada na trilha de auditoria da conta, com autor e data.
Para o Signater aparecer no portal da empresa ao lado dos outros aplicativos, a tela entrega uma URL de início de sessão. Colada no tile do Microsoft My Apps ou do painel do Okta, ela leva a pessoa direto para dentro da plataforma, autenticada no primeiro clique.
O que não muda
O Single Sign-On governa o acesso do seu time à plataforma: quem monta envelope, quem acompanha o andamento, quem administra a conta.
Quem recebe um envelope para assinar segue igual. O cliente abre o link que chegou no e-mail dele, sem instalar aplicativo, sem criar conta no Signater e sem passar pelo provedor de identidade da sua empresa, que não é a empresa dele. A prova de quem ele é continua vindo dos fatores que você escolhe no envelope, como o código enviado por e-mail ou a selfie no momento da assinatura.
Disponibilidade
O Single Sign-On acompanha o plano Enterprise, do mesmo jeito que o White Label e as contas gerenciadas. Não existe módulo de SSO vendido à parte, cobrança por assento autenticado nem pacote mínimo de usuários. A conta está no Enterprise, a tela de SSO aparece para os administradores.
Para conhecer a plataforma antes de conversar sobre plano, o Free resolve: crie uma conta e mande três envelopes por mês, sem cartão de crédito.
