OAuth 2.0, OpenID Connect e JWT

Do zero

Pense num hotel. Você quer que a lavanderia busque uma roupa no seu quarto.

• Você não entrega a sua chave à lavanderia. Pede à recepção um cartão que abre só o seu quarto, só hoje. Isso é o OAuth 2.0: autoriza um sistema (a lavanderia) a acessar algo seu (o quarto) sem receber a sua senha (a chave). O cartão é o access token.
• Antes de emitir o cartão, a recepção confere o seu documento e pode entregar à lavanderia uma ficha dizendo quem você é: “hóspede do 302, Ana Souza”. Isso é o OpenID Connect: autentica, diz quem é o usuário. A ficha é o ID token.
• A ficha (e, muitas vezes, o cartão) vem num formato padrão, com um carimbo da recepção que denuncia qualquer alteração. Esse formato é o JWT. O carimbo é a assinatura; o conteúdo, qualquer um consegue ler.

No mundo real, a recepção é o gov.br, a lavanderia é o sistema em que você clicou em “Entrar com gov.br” e o quarto são os seus dados guardados numa API.

Frase para guardar: OIDC diz quem você é; OAuth diz o que o sistema pode acessar; JWT é o formato em que isso viaja.

Em 1 minuto

• OAuth 2.0 autoriza. Deixa um aplicativo acessar recursos em nome do usuário sem receber a senha dele. Entrega um access token.
• OpenID Connect (OIDC) autentica. É uma camada sobre o OAuth 2.0 que diz quem é o usuário. Entrega um ID token, sempre no formato JWT.
• JWT é um formato. Três partes em Base64URL separadas por ponto: cabeçalho, payload e assinatura.

Exemplo concreto: “Entrar com gov.br”

Comparação: OAuth 2.0 × OpenID Connect × JWT

Por dentro de um JWT

Na prática, o token é uma linha só. Aqui ele foi quebrado nos pontos para mostrar as três partes:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9
.eyJpc3MiOiJodHRwczovL3Nzby5leGVtcGxvLmdvdi5iciIsInN1YiI6IjEyMyIsImF1ZCI6InNpc3RlbWEtdGNlIiwiaWF0IjoxNzkyNjcwNDAwLCJleHAiOjE3OTI2NzQwMDB9
.<assinatura>

Decodificando o Base64URL das duas primeiras partes, sem chave nenhuma:

// Cabeçalho
{ "alg": "RS256", "typ": "JWT" }

// Payload
{
  "iss": "https://sso.exemplo.gov.br",
  "sub": "123",
  "aud": "sistema-tce",
  "iat": 1792670400,
  "exp": 1792674000
}

• iss: quem emitiu · sub: sobre quem é · aud: para quem foi emitido · iat: quando foi emitido · exp: quando expira (aqui, 1 hora depois).
• O payload é só codificado, não criptografado: qualquer um lê. A assinatura garante integridade e autenticidade; para sigilo existe o JWE.

O fluxo certo para cada caso

• Authorization Code com PKCE: apps web, celular e SPA. A RFC 9700 (janeiro de 2025) exige PKCE de clientes públicos.
• Client Credentials: máquina a máquina, sem usuário, como um robô que chama uma API.
• Implicit: não deve ser usado. Resource Owner Password Credentials: proibido (“MUST NOT”). Ambos pela RFC 9700.

Como a FCC cobra

• Autenticação × autorização, ou seja, OIDC × OAuth.
• Papéis do OAuth 2.0 dentro de um cenário.
• Partes e claims do JWT, e se o payload é sigiloso.
• Qual fluxo usar em cada tipo de aplicação.

Pegadinhas

Explique com suas palavras

Explique a um amigo que nunca programou o que acontece quando ele clica em “Entrar com gov.br” e qual a diferença entre OAuth 2.0, OpenID Connect e JWT.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

Quando você clica em “Entrar com gov.br”, o sistema não pede a sua senha: manda você ao gov.br. Lá você faz login, e o gov.br conta ao sistema quem você é e o que ele pode acessar.

Quem você é chega num ID token: isso é o OpenID Connect, que autentica. O que o sistema pode acessar chega num access token: isso é o OAuth 2.0, que autoriza. O ID token vem sempre como JWT, um texto em três partes com uma assinatura que denuncia alteração, mas que qualquer um consegue ler.

Teste-se

Flashcards gerados

Ligação com o estudo de caso

Num caso sobre uma API para jurisdicionados, isto vira proposta: login por OIDC (gov.br), access token curto com escopos mínimos, validação de iss, aud e exp em toda chamada, HTTPS obrigatório e refresh token com rotação.

Fontes da lição

• RFC 6749 (OAuth 2.0)
• RFC 7519 (JWT)
• RFC 7636 (PKCE)
• RFC 9700 (segurança do OAuth 2.0)
• OpenID Connect Core 1.0
• Roteiro do Login Único gov.br