👤
Você
End user · resource owner
Dono da identidade. Autentica no provedor, não no app. O browser é o seu emissário — é ele que carrega os redirects.
SSO é a experiência de entrar uma vez e circular por vários apps. OpenID Connect é o protocolo que tornou isso um padrão na web — o mecanismo por trás de “Entrar com Google”, Okta, Auth0, Microsoft e quase todo botão de login moderno.
Cada app que você usa — e-mail, CI, Figma, o RH da empresa — precisa saber quem você é. A solução ingênua é cada um ter a sua tabela de usuários. Você vira um zelador de senhas. A empresa vira um zelador de vazamentos.
SSO inverte o desenho: um provedor guarda a identidade. Os apps só pedem emprestado um atestado de que você é você. A senha (ou a passkey, ou o MFA) vive num lugar só.
Single Sign-On não é um protocolo. É o resultado: autenticar uma vez num provedor e entrar em vários serviços sem digitar de novo. Pode ser feito com cookies de domínio compartilhado (o jeito antigo da intranet), com SAML (o jeito clássico da empresa) ou com OpenID Connect (o jeito da web moderna).
OpenID Connect — OIDC — é uma camada de identidade em cima do OAuth 2.0. OAuth sozinho responde “este app pode gastar o seu crédito / ler o seu calendário?”. OIDC responde “quem está do outro lado?”. Os dois viajam juntos: o mesmo redirecionamento, o mesmo code, tokens diferentes.
Todo fluxo OIDC é um triângulo. Se você memorizar só isso, o resto se encaixa.
Dono da identidade. Autentica no provedor, não no app. O browser é o seu emissário — é ele que carrega os redirects.
Confia no provedor. Nunca vê a sua senha. Recebe um id_token e, se pediu, um access token para APIs.
Google, Okta, Auth0, Entra ID, Keycloak. Autentica, guarda a sessão, assina o JWT, emite o code.
O app se cadastra no provedor e ganha um client_id (público) e, se for um backend, um client_secret. Também registra a redirect_uri — o único endereço para o qual o provedor devolve o usuário. Sem isso, um site malicioso redirecionaria o code para si.
O caminho padrão hoje é o Authorization Code Flow (com PKCE se o app for público, tipo SPA ou mobile). Clique os passos. O palco mostra quem está falando com quem — e o que atravessa o browser versus o que vai nos bastidores.
Depois do code, o app recebe um id_token: um JSON Web Token. Base64url, três partes separadas por ponto. Clique em cada uma.
O app não confia no token só porque ele chegou. Valida: assinatura (chave pública JWKS do provedor), iss bate com o provedor, aud é o próprio client_id, exp no futuro, nonce é o mesmo que o app gerou. Só então cria a sessão local — um cookie do app, independente do cookie do IdP.
SSO não é o app A avisando o app B. Os dois nem se conhecem. O truque é o cookie de sessão no domínio do provedor. O primeiro login acende essa sessão. O segundo app só redireciona de novo para o mesmo IdP — e o IdP, vendo o cookie, pula a senha e devolve outro code.
Entre nos três apps abaixo. A primeira vez pede credencial. As seguintes, não.
Três confusões que aparecem em toda code review de auth.
o mesmo redirect, intenções diferentes
Redirects pelo browser são o front-channel: visíveis na barra de URL, sujeitos a leak no histórico, em logs, em referrers. Por isso o code é de uso único e vive segundos. A troca code → tokens acontece no back-channel, servidor a servidor, onde o secret (ou o PKCE verifier) não aparece no browser.
SPAs e apps nativos não conseguem esconder um client_secret. PKCE (Proof Key for Code Exchange) faz o app gerar um code_verifier aleatório, mandar o hash (code_challenge) no authorize, e apresentar o verifier só na troca do code. Um atacante que roube o code na URL não consegue o token.
Sair do app apaga a sessão local. A sessão do IdP continua — e é isso que faz o SSO funcionar no próximo app. Logout único (RP-initiated logout) é um pedido extra ao provedor para matar a sessão central. Sem ele, “sair” num app não te tira dos outros.
SSO concentra a confiança num só lugar. Keycloak é um OpenID Provider open source (e o motor do Red Hat Build of Keycloak). Em agosto de 2026 saiu a CVE-2026-18963: um atacante sem login conseguia trocar a senha de qualquer usuário — inclusive admin — e herdar o SSO inteiro.
Esqueci minha senha não pode ser “digitei o username, agora escolho outra”. A prova de posse é o e-mail cadastrado. O IdP manda um action token assinado na mensagem. Só quem abre aquele link — ou seja, quem controla a caixa — pode chegar na tela de senha nova.
Isso é o equivalente, no provedor, do nonce no ID token: um passo que precisa ter acontecido de verdade, não só “a sessão acha que aconteceu”.
O fluxo reset-credentials não validava direito o estado entre os passos. Duas peças se combinaram, a partir do Keycloak 26.0.0:
O fluxo guardava “já mostrei o seletor de autenticador” como uma flag genérica, sem amarrar ao passo que a ligou. Dava para revisitar o fluxo num ponto posterior, como se aquele passo já tivesse sido cumprido.
O autenticador que deveria exigir o action token do e-mail aceitava sucesso mesmo sem essa prova. O fluxo seguia para “definir senha nova”.
CWE-640: recuperação de senha que não prova a identidade
Quem conhecia o username ou o e-mail da vítima iniciava o reset e chegava a gravar credencial nova. Sem clicar no link, sem a caixa de e-mail, sem interação da vítima. O 2FA do login do browser não entra neste fluxo por desenho — reset de senha, no default, pula o OTP. Depois da senha nova, o atacante ainda podia tirar o MFA e ficar dono da conta.
O patch oficial é o PR #51844, reportado por James Paremain e publicado pela Red Hat em 18 de agosto de 2026. Duas correções, as duas necessárias:
Versões corrigidas. Linhas sem patch (26.0–26.3, 26.5) não vão receber correção — sai delas.
Enquanto o patch não sobe: desligar “Forgot password” em todos os realms, inclusive o master. Console: Realm settings → Login → Forgot password → Off. Isso fecha o fluxo vulnerável; usuários perdem o self-service até o upgrade. Keycloak 25.x e anteriores não têm o bug — ele nasceu no 26.0.0.
Depois de patchar: procurar UPDATE_PASSWORD sem evidência de consumo do action token do e-mail na mesma sessão, e tratar contas privilegiadas como comprometidas se a exposição coincidiu com resets estranhos. Forçar senha nova e derrubar sessões de admin não é paranoia, é higiene.
Fontes: Red Hat CVE-2026-18963, keycloak#51833, notas 26.7.2. Sem receita de exploração aqui — só o mecanismo e o remendo.
Este provedor vai atestar sua identidade para o app.