SSO e federação: SAML × OAuth 2.0 × OIDC

A ideia que organiza o assunto

A pergunta que este tópico parece fazer — autenticação ou autorização? — não é a pergunta que ele de fato cobra. Vale medir antes de decorar: nos 46 itens do corpus, três itens Certos chamam o OAuth 2.0 de protocolo de autenticação ou lhe atribuem o login único (“o protocolo OAuth 2, adotado por instituições de governo para autenticação e controle dos acessos às suas APIs”, “as etapas do fluxo de autenticação do protocolo”, “Segundo o OAuth 2.0, o SSO ocorre quando um usuário, ao fazer login em um aplicativo, automaticamente faz login em outros”), e cinco enunciados de grupo abrem com “protocolo de autenticação OAuth 2.0” ou “framework de autenticação OAuth 2.0”. Quem usar a régua “OAuth não é autenticação, logo o item está errado” perde esses três pontos e não ganha nenhum: um único item em 46 é decidido por esse eixo.

O que organiza o assunto, então, é uma pilha de quatro camadas e um elenco de quatro papéis. A pilha, de baixo para cima:

OAuth 2.0 (RFC 6749) é a base — um arcabouço de autorização delegada. Ele responde o que este aplicativo pode fazer em meu nome, e a resposta é um token de acesso com escopo e prazo.
OpenID Connect é a camada de identidade construída sobre o OAuth 2.0. Ele acrescenta a resposta à outra pergunta — quem é o usuário — na forma de um token de identidade assinado.
JWT (RFC 7519) é formato, não protocolo. É o envelope JSON assinado em que o token de identidade sempre vem e em que o token de acesso muitas vezes vem. Formato não autentica nem autoriza nada: ele transporta a decisão que outro componente tomou.
SAML 2.0 fica ao lado, não em cima: é o padrão independente, anterior e em XML, que resolve federação e SSO sem nenhuma relação de herança com os outros três.

O elenco se decora pelo verbo, e é ele que decide a maior parte dos itens de papel: o proprietário do recurso concede, o servidor de autorização emite, o servidor de recursos entrega, o cliente pede e apresenta. Trocar qualquer par desses verbos é a forma mais frequente de item errado no tópico.

A régua que substitui a do rótulo é simples: não pergunte que palavra o item usa, pergunte o que ele diz que trafega e quem faz o quê. “O OAuth transmite dados de autenticação” está errado porque o que trafega é autorização; “o OAuth é usado para autenticação nas APIs do governo” está certo porque o mecanismo descrito — token limitado, sem senha — é o do OAuth.

Por que se usa (e o que custa)

O problema que o OAuth resolve é antigo e concreto: antes dele, para que um aplicativo acessasse seus dados em outro serviço, você entregava a senha ao aplicativo. A senha dá acesso total, por prazo indeterminado, e não se revoga sem trocar a senha em todo lugar. O OAuth substitui isso por um token de escopo delimitado e prazo curto, revogável isoladamente, e essa cláusula — “sem revelar credenciais”, “sem a necessidade de envio do nome de usuário e da senha”, “sem a necessidade de compartilhamento de senhas” — aparece literalmente em três itens Certos do corpus.

O custo tem três faces. Primeira: o token do OAuth 2.0 é ao portador — quem o tem, usa —, de modo que toda a confidencialidade do protocolo é terceirizada ao TLS, e um token vazado vale até expirar. Segunda: o JWT é autocontido, e é por isso que ele é difícil de revogar — o servidor o aceita pela assinatura, sem consultar estado, e daí decorrem todas as boas práticas do tópico (prazo curto, refresh token, escopo mínimo). Terceira: o SSO concentra o risco — uma credencial comprometida entrega todas as aplicações de uma vez, e uma sessão que fica aberta continua valendo em todas elas. As compensações que a prova cobra são sempre as mesmas duas: MFA e logout global.

Como funciona

O fluxo abstrato do OAuth 2.0. A ordem nunca muda e é por ela que se julgam os itens de fluxo: o cliente solicita autorização ao proprietário do recurso; o proprietário concede (na prática, o servidor de autorização o autentica e apresenta a tela de consentimento); o cliente troca essa concessão por um token de acesso no servidor de autorização; apresenta o token ao servidor de recursos; e o servidor de recursos, validado o token, entrega o recurso. A RFC 6749 exige que o servidor de autorização, ao pedir consentimento, informe ao dono o cliente, o escopo e a vida útil da autorização solicitada — esse trio é literal e já caiu como item Certo.

As concessões. O código de autorização é a concessão recomendada, e hoje sempre com PKCE: o token não passa pelo navegador, e o cliente se autentica na troca. O implícito devolve o token direto no redirecionamento — existe na especificação e é desaconselhado pelas boas práticas, e o corpus tem itens Certos dos dois tipos, um afirmando a existência e outro recomendando abandoná-lo. O client credentials é o que permite à aplicação obter acesso por conta própria, sem usuário envolvido. O refresh token não é concessão de entrada: serve para obter novos tokens de acesso sem novo login.

O que o OpenID Connect acrescenta. Ao fim de um fluxo OIDC o cliente recebe dois tokens: o de acesso, herdado do OAuth 2.0, e o ID Token, que é um JWT e deve ser assinado com JWS — é a assinatura obrigatória que torna o OIDC utilizável como autenticação, e é o motivo de o OAuth 2.0 puro não servir para isso. Atributos adicionais de perfil ficam no endpoint UserInfo, alcançado com o token de acesso. Os parâmetros de identidade — max_age, nonce, prompt, acr_values — são do OIDC, não do OAuth 2.0: max_age fixa o tempo máximo, em segundos, desde a última autenticação, e ultrapassado esse limite o usuário tem de se autenticar de novo, com o instante registrado na claim auth_time.

JWT por dentro. Três partes codificadas em Base64URL e separadas por pontos: cabeçalho (tipo do token e algoritmo de assinatura), payload (as claims) e assinatura. A assinatura pode ser simétrica (HMAC com segredo compartilhado) ou assimétrica (par de chaves, RSA ou ECDSA). O payload é codificado, não cifrado — qualquer um lê. As claims se dividem em registradas (iss, sub, aud, exp, nbf, iat, jti; nomes reservados pela RFC e todas de uso opcional), públicas (livres, mas registradas no IANA JWT Registry ou com nome resistente a colisão) e privadas (acordadas entre as partes que concordam em usá-las, para trocar informação entre elas).

SAML 2.0. Três partes: o sujeito, o provedor de identidade — que autentica e emite a asserção — e o provedor de serviços, que consome a asserção e libera o acesso. Tudo em XML, assinado com XML Signature. O SSO nasce de o provedor de serviços confiar na asserção em vez de autenticar por conta própria — que é a mesma ideia do OIDC com outro formato.

Keycloak. Servidor de identidade de código aberto: autenticação única, federação de identidades, autorização e emissão de tokens, falando OpenID Connect, OAuth 2.0 e SAML. A troca de token permite entregar um token que já se possui e receber outro — inclusive trocar um token do Keycloak por um token externo, e o inverso. É a solução de SSO adotada pela PDPJ-Br, com OAuth2 como protocolo. O RADIUS, que aparece ao lado dele em item Certo, é outra coisa: protocolo de AAA em rede, que pode ser integrado ao conjunto.

O que decide os itens

Os quatro papéis do OAuth 2.0, pelo verbo — a tabela que resolve mais itens que qualquer outra:

papel	o verbo dele	o que ele não faz
proprietário do recurso (dono, usuário final)	concede a autorização	não emite token
cliente (a aplicação)	pede e apresenta o token	não recebe nem guarda a senha do usuário
servidor de autorização	autentica o dono, colhe o consentimento e emite o token	não hospeda o recurso
servidor de recursos	valida o token e entrega o recurso	não concede acesso

Os quatro padrões, lado a lado:

	o que é	responde	formato	partes
SAML 2.0	padrão OASIS de federação	quem é o usuário	XML	sujeito, IdP, SP (3)
OAuth 2.0	arcabouço de autorização (RFC 6749)	o que o cliente pode fazer	token opaco ou JWT	4 papéis
OpenID Connect	camada de identidade sobre o OAuth 2.0	quem é o usuário	JWT (ID Token)	usuário, RP, OP
JWT	formato de token (RFC 7519)	nada — só transporta	JSON em Base64URL	—

Token de acesso × token de identidade × refresh token — o de acesso representa uma autorização emitida ao cliente e é apresentado ao servidor de recursos; o de identidade afirma quem é o usuário, é sempre JWT assinado e é consumido pelo cliente, nunca pela API; o refresh token só serve para obter novos tokens de acesso sem novo login. Item que faz o token de acesso carregar a identidade do usuário trocou os dois primeiros.

Autenticação × autorização — onde a distinção decide e onde não decide:

a frase do item	vale como erro?
chama o OAuth 2.0 de “protocolo de autenticação”	não — a banca escreve isso em enunciado e em item Certo
diz que o OAuth serve para login único / SSO	não — item Certo no corpus
diz que o OAuth transmite dados de autenticação	sim — isso é do OpenID; o OAuth transporta autorização
diz que o OIDC é construído sobre o JWT	sim — é construído sobre o OAuth 2.0

Conceder × emitir × validar — o dono concede, o servidor de autorização emite, o servidor de recursos valida. As duas trocas medidas no corpus são exatamente essas: “o servidor de recurso” no lugar do proprietário e “o dono do recurso é responsável pela emissão dos tokens” no lugar do servidor de autorização.

Tipos de claim:

tipo	quem define	para quê
registradas (reserved)	a RFC 7519 reserva o nome	`iss`, `sub`, `aud`, `exp`…, todas opcionais
públicas	quem usa, mas registrando no IANA ou com nome resistente a colisão	evitar colisão de nomes
privadas	as partes que concordam em usá-las	compartilhar informação entre elas

Keycloak é × não é — é gestão de identidades e acessos, SSO, federação, emissão e troca de tokens. Não é esteira de CI/CD, não é orquestrador nem administrador de infraestrutura Docker. Rodar em contêiner não é administrar contêineres.

Existir na especificação × ser recomendado — o fluxo implícito existe e é desaconselhado; as duas afirmações são Certas em itens diferentes. Leia se a frase afirma existência ou recomendação antes de julgar.

SSO × logout — o login único tem contrapartida: o single logout, global, é parte do modelo. Item que concede o SSO e nega o logout único está errado.

Números que caem


OAuth 2.0	RFC 6749 — o único número que o tópico cobra com frequência
Bearer token	RFC 6750
JWT	RFC 7519
Boas práticas de segurança do OAuth 2.0	RFC 9700 (antes draft-ietf-oauth-security-topics)
Troca de token (token exchange)	RFC 8693
RADIUS	RFC 2865
partes do JWT	3: cabeçalho, payload, assinatura — separadas por ponto, em Base64URL
papéis do OAuth 2.0	4: proprietário, cliente, servidor de autorização, servidor de recursos
partes do SAML	3: sujeito, provedor de identidade, provedor de serviços
fluxos do OpenID Connect	3: código de autorização, implícito, híbrido
tipos de claim no payload	3: registradas, públicas, privadas
tokens devolvidos em um fluxo OIDC	2: token de acesso e token de identidade
`max_age`	tempo máximo em segundos desde a última autenticação (OIDC, não OAuth 2.0)

Como a CEBRASPE derruba você aqui

Dos 46 itens, 19 são Errados, e a medição é quase monotemática: 9 deles — quase metade — apenas viram o operador de uma frase da especificação. Depois vêm 5 em que a atividade descrita pertence a outro produto ou protocolo, 4 em que um termo é trocado pelo vizinho do par e 1 quantificador esticado. Não há aqui erro de cálculo, de número nem de sintaxe de token: o tópico inteiro se joga no verbo e no advérbio.

A frase da especificação, negada — 9 dos 19 itens errados. É o molde dominante: a banca pega uma sentença da RFC e inverte o verbo, o advérbio ou a ordem. “não separa o papel do cliente do papel do proprietário do recurso” (a RFC 6749 abre dizendo que separa); “os servidores de autorização podem processar parâmetros de solicitação não reconhecidos” (a RFC manda ignorar); “obtenha acesso ilimitado a um serviço HTTP” (o resumo da RFC diz limitado); “que os servidores nos quais os retornos de chamada estão hospedados exponham redirecionadores abertos” (a boa prática manda não expor); “o uso de tokens não assinados” como vulnerabilidade do OIDC (o ID Token deve ser assinado); “autenticar usuários antes que eles forneçam credenciais válidas” (o token é emitido depois); “o single logout deve ser realizado individualmente”; e a inversão do próprio mecanismo, acesso obtido “por meio da inserção do nome e da senha do usuário no cabeçalho” quando é justamente o token que viaja ali. A defesa é mecânica: localize a sentença original, troque o operador de volta e veja se sobra algo que a especificação realmente diz. Palavras que quase sempre marcam o ponto de inversão: não, ilimitado, antes, individualmente, podem, exponham.

O trabalho de outro, no nome certo — 5 dos 19. O produto ou o protocolo existe, a atividade descrita existe, e as duas não se encontram: Keycloak que serviria para “implementar com segurança CI (continuous integration) e CD (continuous deployment)”; Keycloak “cujo objetivo principal é gerenciar a segurança em contêineres à medida que ele administra a infraestrutura de docker”; OAuth que daria acesso seguro “por transmitir dados de autenticação entre consumidores e provedores de serviços” (isso é do OpenID); SAML como padrão de autenticação “sendo o OAuth2 a sua correspondente implementação”; max_age que “faz que as partes envolvidas em um processo de autorização busquem a data atual do sistema”. A defesa: leia a atividade primeiro e nomeie você mesmo quem a executa; só depois confira com o nome escrito no item.

O vizinho do par — 4 dos 19. Um termo trocado por outro da mesma família, com o resto da frase correto: “a parte com capacidade de conceder acesso aos recursos protegidos é o servidor de recurso” (é o proprietário); “os public claims são utilizados para compartilhar informações entre aplicações” (são os private); “OpenID Connect […] construído no protocolo do JSON Web Token” (é sobre o OAuth 2.0); “O SAML, assim como o JWT, utiliza JSON” (o SAML é XML). São sempre pares que a tabela de O que decide os itens já separa — proprietário × servidor de recursos, público × privado, base × formato, XML × JSON.

Quantificador esticado — 1 dos 19. Apenas um item: JWT que “implica a autenticação e a autorização dentro de qualquer sessão”. Neste tópico, qualquer, sempre e todo não são o sinal barato que são em outros assuntos — a banca prefere inverter a esticar.

E o que este tópico não cobra. Vale saber onde não gastar tempo: em 46 itens, o SAML é citado em quatro, e em apenas três ele decide alguma coisa — no quarto aparece só em lista de padrões abertos. Nenhum pede binding, perfil, artifact, metadado ou estrutura de asserção: o que se cobra é XML × JSON e as três partes do processo. Não há um único item sobre PKCE, sobre introspecção de token, sobre revogação, sobre device flow, sobre nonce ou sobre o endpoint UserInfo. O peso está em OAuth 2.0 (21 dos 46 itens o citam), JWT (10), OpenID Connect (9) e Keycloak (5).

Erros clássicos

Usar “OAuth não é autenticação” como veto. É verdade no plano conceitual e inútil como régua de prova: a banca escreve “protocolo de autenticação OAuth 2.0” no enunciado e marca Certo o item que diz que o governo o usa “para autenticação”. A distinção só decide quando o item afirma o que o token transporta — aí sim, o OAuth transporta autorização e quem transporta autenticação é o OpenID.

Construir o OpenID Connect sobre o JWT. A base é o OAuth 2.0; o JWT é o formato do token que a camada emite. Insumo não é fundação.

Achar que o SAML é a versão antiga do OAuth, ou que um implementa o outro. São padrões independentes, de organismos diferentes, resolvendo problemas diferentes — e um é XML, o outro é token.

Confundir conceder com emitir. O dono do recurso concede; quem emite token é o servidor de autorização. A segunda metade da frase é onde essa troca costuma aparecer, com a primeira metade correta para dar credibilidade.

Supor que o payload do JWT é secreto. Ele é codificado em Base64URL, não cifrado: qualquer um lê. A assinatura garante integridade e autenticidade, não confidencialidade — e nunca coloque dado sensível ali.

Achar que “reservada” quer dizer “obrigatória”. As claims registradas da RFC 7519 têm o nome reservado e o uso opcional, iss inclusive.

Tratar token válido como acesso total. Quem delimita é o escopo; “limitado” é palavra estrutural do OAuth 2.0 e trocá-la por “ilimitado” já resolve o item.

Esperar que o TLS seja opcional. O token é ao portador; sem TLS, interceptá-lo é o mesmo que roubá-lo. O protocolo não tem proteção própria de transporte.

Dar ao Keycloak tarefas de esteira ou de contêiner. Ele é servidor de identidade. Rodar dentro de um contêiner não o transforma em quem administra contêineres.

Apresentar o SSO como ganho puro de segurança. Ele concentra o risco em uma credencial e em uma sessão; os controles que a prova cobra como compensação são MFA e logout global.