O que é um portal de acesso único e por que ele existe
Um portal de acesso único funciona como um ponto centralizado de autenticação. Você entra uma vez com suas credenciais e, a partir daí, tem acesso a múltiplos sistemas sem precisar logar em cada um separadamente. Do lado técnico, isso geralmente usa protocolos como SAML 2.0 ou OpenID Connect para trocar tokens de identidade entre o provedor de identidade e os serviços de confiança. Não é mágica, apenas infraestrutura bem configurada. No Brasil, o termo aparece bastante em ambientes governamentais, corporativos e educacionais. Muitos órgãos usam o GOV.BR como identidade digital, mas empresas privadas e universidades montam suas próprias instâncias. O objetivo principal é reduzir a quantidade de senhas que alguém precisa lembrar ecentralizar o controle de acesso.
Como montar um portal de acesso único na prática
A primeira coisa que você precisa decidir é qual protocolo vai usar. Se o seu ambiente é mais tradicional e você tem aplicações legacy, SAML 2.0 ainda é o padrão mais seguro. Se está começando do zero ou trabalha com aplicações modernas baseadas em nuvem, OpenID Connect com OAuth 2.0 é mais simples de implementar. Aqui estão os passos que eu sigo sempre:
Cadastrar o provedor de identidade. Isso pode ser um serviço como Keycloak, Azure AD, Okta, ou uma solução própria desenvolvida internamente. O Keycloak é gratuito e roda em Docker, então é barato para começar. Eu configurei um Keycloak rodando em um container leve com apenas 2GB de RAM e consegui suportar cerca de 500 usuários simultâneos sem problemas. Configurar os services de confiança. Cada aplicação que vai usar o SSO precisa ser registrada no provedor de identidade. Você define o relay state, o callback URL, e o mapeamento de atributos. Esquecer o callback URL é um erro comum que quebra tudo. A aplicação vai redirecionar para o portal, o usuário faz login, e o portal retorna um token firmado para aquela URL específica. Se o path não bater exatamente, o token é rejeitado.
Implementar o middleware de autenticação. A maioria das linguagens tem bibliotecas prontas. Para PHP, o league/oauth2-client funciona bem. Para Node.js, existe o passport com estratégia SAML ou JWT. Eu já vi gente tentando escrever a validação de token do zero. Não faça isso. Você vai perder dias e ainda deixar brechas de segurança.
Problemas reais que aparecem com portal acesso unico
A maioria dos problemas técnicos que eu encontrei ao longo do tempo vêm de três fontes: certificados TLS vencidos, configuração errada de metadados SAML, e sessão que não expira corretamente quando o usuário faz logout em uma aplicação mas continua logado nas outras. O caso mais específico que eu tive foi com um sistema legado em Java que usava uma versão antiga do Spring Security. Quando eu configurava o SAML com o Keycloak, o sistema recusava o assertion porque o XML vinha assinado com SHA-256 e a aplicação só aceitava SHA-1. A solução foi editar o metadata do Spring Security e adicionar explicitamente o algorithm URIs que eu queria, algo como XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA256. Sem isso, o login nunca funcionava e o erro era genérico demais para ajudar. Passei duas horas rastreado isso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro problema comum é a sincronização de atributos. Se o portal envia um email para a aplicação e o campo vem vazio ou com formato diferente, a aplicação pode falhar silenciosamente. Sempre mapeie os atributos manualmente e teste com dados reais, não com valores fictícios.
Download e configurações iniciais
Se você quer começar do zero, o Keycloak é a opção mais acessível. O download oficial está em keycloak.org/downloads. A versão Community é gratuita e cobre a maioria dos casos de uso. Para produção, considere pagar por suporte ou usar uma distribuição como o RH-SSO da Red Hat. O comando básico para rodar localmente é:
docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:latest start-dev Isso levanta o portal em localhost:8080 em poucos minutos. A partir daí, você cria um realm, cadastra um cliente, e configura o protocolo. O Keycloak gera automaticamente os metadados SAML e o discovery document do OpenID Connect. Só copiar e colar na aplicação.
Pitfalls avançados que poucos mencionam
A primeira coisa que todo mundo erra é configurar o SSO apenas para subdomínios. Cookies de sessão não funcionam de forma cross-domain por padrão. Se sua aplicação A está em app1.empresa.com e a aplicação B em app2.empresa.com, você precisa ajustar o domínio do cookie no provedor de identidade para .empresa.com, mas isso exige que todos os serviços confiem no mesmo provedor. Senão, o cookie não é enviado corretamente e o usuário precisa logar em cada domínio separadamente, quebrando a proposta do SSO. A segunda coisa é o tempo de vida do token. Tokens muito curtos forçam refresh constante, o que gera tráfego desnecessário e pode sobrecarregar o provedor. Tokens muito longos são risco de segurança. Um equilíbrio razoável é access token com 15 minutos e refresh token com 24 horas. Isso reduz o número de chamadas de renovação pela metade em relação à configuração padrão.
Uma limitação importante que ninguém gosta de admitir: SSO não resolve problemas de autorização. O portal de acesso único verifica quem você é, não o que você pode fazer. Se você precisa de controle granular de permissões por recurso, vai precisar implementar um sistema separado de autorização ou usar políticas baseadas em atributos (ABAC) no próprio provedor de identidade. O Keycloak suporta isso com o resource server e políticas de avaliação, mas a curva de aprendizado é relevante. Outro ponto que causa dores de cabeça: múltiplos provedores de identidade. Algumas organizações têm usuários de parceiros que autenticam via Fediverse ou SAML externo enquanto funcionários usam o Google Workspace como IdP. Isso é possível com o conceito de federation, mas cada relacionamento extra aumenta a complexidade de configuração e o tempo de troubleshooting proporcionalmente.
Quando não usar um portal de acesso único
Se você tem menos de 20 aplicações e a maioria é interna com autenticação local, o custo de implementação pode não valer a pena. Uma simples página de login compartilhada com banco de dados centralizado resolve em menos tempo. Se o seu negócio depende de conformidade regulatória com exigências específicas de auditoria, como LGPD em níveis elevados ou setores financeiros com normas do Bacen, considere antes se o provedor de identidade que você escolher atende aos requisitos de logging e retenção de evidências. Keycloak gera logs, mas a granularidade depende da configuração. Ferramentas comerciais como Okta ou Azure AD oferecem dashboards prontos, mas cobram por usuário ativo.
