Login único para a equipe do seu MSP

Os seus técnicos entram no KairosLink com a identidade da sua empresa, sem uma senha a mais para lembrar. O login único roda sobre OpenID Connect: quando alguém sai do MSP e a conta dessa pessoa é desligada no provedor de identidade, ela para de entrar no painel naquele mesmo momento.

Três provedores, sem URLs para colar à mão

Os provedores com descoberta automática são Microsoft Entra ID, Okta e Google Workspace. O formulário pede só a parte que muda (o identificador do tenant no Entra, o domínio no Okta) e monta a URL de descoberta sozinho. Com o Google ele não pede nada, porque a URL é sempre a mesma. Ninguém precisa editar o meio de uma URL longa dentro de um campo estreito.

O domínio é comprovado no DNS, e comprovado de novo

Para habilitar um domínio você tem que provar que ele é seu: publique um registro TXT no DNS e o KairosLink verifica. Essa prova não vale para sempre. A cada 7 dias o registro é verificado de novo e, se ele sumiu, o domínio para de permitir logins. Um domínio que é vendido ou um cliente que vai embora perdem o acesso sem ninguém ter que lembrar de revogar.

Domínios de e-mail públicos nunca podem ser reivindicados. Reivindicar um domínio significa ficar com todos os logins desse domínio: se alguém reivindicasse o gmail.com, puxaria qualquer usuário do Gmail da plataforma para o provedor de identidade dele.

O seu provedor conhecer a pessoa não abre a porta

O provedor de identidade prova quem é uma pessoa. Ele não prova que essa pessoa deve ver o painel que acessa remotamente o parque de todos os seus clientes. Essa segunda decisão é humana: cada novo acesso federado cai em uma fila e é aprovado por alguém com a permissão de gestão de usuários.

Uma recusa feita por engano pode ser desfeita, porque as recusas recentes ficam ao alcance na mesma tela. O menu mostra a contagem de solicitações pendentes, então ninguém fica esperando que alguém lembre de olhar.

O segundo fator é lido do token, não presumido

O KairosLink lê do token o que a pessoa fez para se autenticar, e só uma lista fechada de métodos conta como segundo fator: aplicativo autenticador, chave de hardware, biometria, SMS e as variantes próprias de cada provedor. Só a senha não conta, por mais que o provedor a anuncie com orgulho.

As assinaturas aceitas são apenas assimétricas: RS256, RS384, RS512, ES256 e ES384. Um token sem assinatura ou com algoritmo simétrico nunca é aceito, e essas são as duas formas clássicas de forjar um JWT.

Perguntas frequentes