OAuth 2.1

OAuth é a palavra que aparece em todo botão de “Entrar com o Google” e em todo aviso de “tal aplicativo quer acessar sua conta”, mas o que ela resolve quase nunca é dito em voz alta. O problema tem nome: autorização delegada. A pergunta é como deixar um aplicativo agir em seu nome sobre um recurso protegido, ler suas fotos, criar um evento na sua agenda, sem que você entregue a ele a sua senha.

A imagem que os próprios autores do OAuth usaram é a da chave do manobrista. Um carro de luxo vem com duas chaves: a sua, que abre tudo, e a do manobrista (a valet key), que liga o motor e anda alguns metros mas não destranca o porta-malas nem o porta-luvas. Entregar a senha a um aplicativo é dar a chave mestra: acesso total, por tempo indeterminado, sem como voltar atrás a não ser trocando a senha. OAuth existe para emitir a chave do manobrista: um acesso limitado no escopo, limitado no tempo e revogável sem tocar na sua credencial.

Autorizar não é autenticar

Vale fixar isso cedo, porque é a confusão mais comum e a mais cara. OAuth responde “este aplicativo pode ler as suas fotos?”, não “quem é você?”. Ele cuida de autorização (permissão de acesso a um recurso), não de autenticação (a prova de identidade de quem está do outro lado). A distinção não é pedantismo: um access token diz o que o portador pode fazer e, de propósito, não afirma nada sobre quem ele é nem se ele ainda está presente. Montar um login só com OAuth, lendo “conseguiu acessar o recurso” como “logo, é fulano”, é a origem de uma classe inteira de falhas de segurança.

O padrão que preenche essa lacuna é o OpenID Connect (OIDC), uma camada de autenticação montada sobre o OAuth. Ele acrescenta um artefato próprio, o ID token (um JWT assinado com dados de identidade), e é o que de fato roda por trás dos botões de “Entrar com”. A trilha trata OIDC como vizinho, não como tema central; o ID token reaparece na página de tokens justamente para marcar onde passa a fronteira entre acesso e identidade.

Por que 2.1, e não 2.0

OAuth 2.1 não é um protocolo novo. É o OAuth 2.0 (a RFC 6749, de 2012) com uma década de lições de segurança incorporadas ao texto-base e tornadas obrigatórias. O que estava espalhado por várias extensões (o PKCE da RFC 7636, o uso de bearer tokens da RFC 6750, o Security Best Current Practice da RFC 9700) foi reunido num documento só, e o que se provou inseguro foi retirado. Três decisões resumem o espírito da revisão: o PKCE deixa de ser opcional e passa a valer para todo cliente, os grants implícito e de senha saem de cena, e a comparação da redirect URI passa a ser exata. A página o que mudou detalha cada corte com a razão de segurança por trás dele.

Convém saber o status. Em meados de 2026 a 2.1 ainda é um Internet-Draft da IETF (draft-ietf-oauth-v2-1, na revisão 15, de março de 2026), não uma RFC publicada. Isso não a torna experimental: como ela só codifica práticas que os grandes provedores de identidade já seguem, adotar “OAuth 2.1” hoje é adotar o OAuth 2.0 configurado do jeito seguro, com um nome que anuncia essa postura.

O mapa da trilha

Personas apresenta os quatro papéis (resource owner, client, authorization server e resource server) e a divisão entre cliente público e confidencial, que decide quase tudo o que vem depois.

Tokens e escopos cataloga o que circula entre esses papéis: o authorization code, o access token, o refresh token, o ID token do OIDC, e os scopes que limitam cada acesso.

Fluxos põe as peças em movimento, com o Authorization Code mais PKCE passo a passo e os grants de client credentials, device e refresh.

O que mudou lista o que a 2.1 tornou obrigatório e o que removeu, cada item amarrado ao ataque que ele fecha.

MCP sobre OAuth 2.1 mostra como o Model Context Protocol apoia sua autorização nesse padrão, e por que escolheu a 2.1 em vez da 2.0.

Palavras-chave

Conceitos: autorização delegada, autorização vs autenticação, valet key, escopo, consentimento Padrões: OAuth 2.1, OAuth 2.0, OpenID Connect, PKCE, RFC 6749, RFC 9700 Artefatos: access token, refresh token, ID token, authorization code