Add-on SSO
Add-on SSO permite que alunos e admins entrem na evob com as credenciais corporativas já existentes.
O que o add-on SSO adiciona
Com o SSO habilitado, o login na evob é feito pelo provedor de identidade da organização — sem criar nova senha:
| Elemento | O que faz | |---|---| | Login único | Aluno entra com o mesmo usuário e senha do Google Workspace, Microsoft 365 ou outro IdP | | Provisionamento automático | Conta na evob criada automaticamente no primeiro login, sem cadastro manual | | Desativação automática | Quando o colaborador sai da organização e a conta no IdP é desativada, o acesso à evob é encerrado | | Mapeamento de grupos | Grupos do IdP podem ser mapeados para lojas ou cursos na evob | | SAML 2.0 e OIDC | Suporte aos dois protocolos mais usados em ambientes corporativos |
Provedores suportados
| Provedor | Protocolo | |---|---| | Google Workspace | OIDC | | Microsoft 365 / Azure AD | SAML 2.0 / OIDC | | Okta | SAML 2.0 / OIDC | | OneLogin | SAML 2.0 | | Active Directory (ADFS) | SAML 2.0 | | Outros provedores SAML/OIDC | Configuração manual |
Onde gerenciar
Após habilitar em Plataforma > Add-ons > SSO > Habilitar:
- Configuração do provedor: Plataforma > SSO > Configurações
- Mapeamento de grupos: Plataforma > SSO > Grupos
- Status das conexões: Plataforma > SSO > Diagnóstico
Tempo de configuração
O SSO requer configuração bilateral — na evob e no provedor de identidade. Tempo médio:
| Provedor | Tempo estimado | |---|---| | Google Workspace | 15–30 minutos | | Microsoft Azure AD | 30–60 minutos | | Outros (com suporte técnico) | 1–3 horas |
Boas práticas
✅ Faça
- Teste o SSO com um usuário piloto antes de migrar toda a base — verifique login, provisionamento e acesso às lojas corretas
- Mantenha o login por e-mail/senha habilitado durante o período de transição — desabilite apenas após confirmar que 100% dos usuários conseguem entrar via SSO
- Documente o processo de login SSO para os alunos — muitos não sabem o que é SSO e ficam confusos ao ver uma tela diferente do habitual
❌ Não faça
- Desabilitar o login por e-mail/senha antes de confirmar que todos os usuários têm conta ativa no IdP — quem não tiver ficará bloqueado sem possibilidade de recuperação de senha
- Configurar o SSO em produção sem testar em ambiente de homologação — erros de configuração SAML bloqueiam todos os logins simultaneamente
- Ignorar o mapeamento de grupos — sem ele, todos os usuários provisionados via SSO chegam sem acesso a nenhuma loja
Erros comuns
"Configurei o SSO mas o botão de login não aparece para os alunos"
Verifique se a habilitação foi concluída incluindo todas as etapas do assistente em Plataforma > SSO > Configurações. O botão de SSO só aparece após a configuração estar completa e validada.
"Alunos que usavam e-mail/senha não conseguem entrar após ativar o SSO"
O SSO não migra senhas existentes — ele cria um método adicional de login. Se o login por e-mail/senha foi mantido habilitado, os alunos devem continuar conseguindo entrar normalmente. Se foi desabilitado, eles precisam usar o "Esqueci minha senha" para criar uma nova.
"Um ex-colaborador ainda consegue entrar na evob via SSO"
Se a conta no IdP ainda está ativa, o SSO também está. A desativação precisa ser feita no provedor de identidade — a evob reflete o estado do IdP. Verifique e encerre a conta no IdP imediatamente.
"Erro 'invalid_request' ou 'assertion expired' no login SSO"
Esses erros indicam descompasso de horário entre os servidores ou metadados desatualizados. Verifique: (1) se os metadados SAML importados na evob são os mais recentes do IdP, (2) se o horário do servidor do IdP está sincronizado (NTP).
Próximos passos
Foi útil este artigo? 👍 👎 Falar com CS (em produção) · Pergunte ao Vob 🤖 (em produção) Última atualização: 2026-05-06