Blog/Artigos · Segurança
Autorização delegada, o token que carrega poder, PKCE e a diferença entre provar identidade e conceder acesso, com Okta, Auth0 e Keycloak.
O Talmud firma um princípio que a lei usa até hoje: o enviado de uma pessoa é como ela própria; o que o shaliach faz dentro do mandato vale como se o mandante tivesse feito. Guarde a palavra mandato. OAuth 2.0 é esse princípio aplicado ao software: um aplicativo age em seu nome, com a autoridade que você delegou, dentro do escopo que você autorizou, e sem nunca receber a sua senha. O token é a carta selada que o enviado carrega, e entender o que está escrito nela é entender toda a segurança do fluxo.
Antes do OAuth, deixar um aplicativo agir por você significava dar a ele a sua senha, o equivalente a entregar a chave de casa para quem só precisava regar as plantas. OAuth 2.0, padronizado na RFC 6749, resolveu isso separando os papéis: você é o dono do recurso, o aplicativo é o cliente, e um servidor de autorização emite ao cliente um token com poder limitado, sem que a sua senha jamais passe por ele. O enviado recebe um mandato, não a sua identidade inteira.
O poder do token é limitado por escopo: ler o calendário, sim; apagar e-mails, não. Essa é a força do modelo e também sua armadilha, porque o escopo amplo demais é a chave de casa disfarçada de mandato de regar planta. Okta, Auth0 e Keycloak implementam o padrão, mas quem define o escopo é quem desenha a integração, e escopo largo concedido por conveniência é o erro mais comum que eu encontro em revisão.
Aqui mora a confusão mais cara do mercado: OAuth 2.0 é sobre autorização, não sobre identidade. O access token diz o que o portador pode fazer, não quem ele é, e usar access token como prova de login é a origem de uma classe inteira de vulnerabilidades. Foi para preencher essa lacuna que a OpenID Foundation criou o OpenID Connect (OIDC), uma camada de identidade sobre o OAuth 2.0.
OIDC acrescenta o id_token, um JWT assinado que afirma quem é o usuário, quando e como ele autenticou, e para qual cliente aquele token foi emitido. A carta do enviado passa a ter duas partes: uma diz o que ele pode (access token, do OAuth), outra diz de quem ele vem (id_token, do OIDC). Confundir as duas é entregar o mandato para o portador errado.
| Pergunta | OAuth 2.0 | OpenID Connect |
|---|---|---|
| O que responde | o que o cliente pode fazer | quem é o usuário autenticado |
| Token principal | access token | id_token (JWT assinado) |
| Camada | autorização | identidade sobre o OAuth 2.0 |
| Erro comum | escopo largo demais | usar access token como prova de login |
Dos fluxos do OAuth, o Authorization Code é o recomendado, e o Implicit foi aposentado justamente por expor o token. Mas o Authorization Code puro tinha um flanco em aplicações públicas, como mobile e SPA, onde o segredo do cliente não pode ser guardado: um atacante que interceptasse o código de autorização poderia trocá-lo por um token. PKCE, a RFC 7636, fechou esse flanco e hoje é obrigatório na prática.
PKCE funciona como um selo que só o remetente original consegue reproduzir: o cliente gera um segredo aleatório, envia o hash dele ao pedir o código e revela o segredo original ao trocar o código pelo token. Quem interceptou o código não tem o segredo, então a troca falha. No PicPay eu redesenhei a autenticação mobile com OAuth 2.0 e PKCE exatamente por isso, eliminando o token de longa duração que era o ativo mais visado.
O código interceptado é inútil sem o verificador original. O selo prova que quem troca é quem pediu.
Os erros que viram incidente são conhecidos e repetidos: redirect_uri sem validação estrita, que permite roubar o código; access token de vida longa, que amplia a janela de estrago; refresh token sem rotação, que vira credencial permanente; e ausência de validação de audiência, que faz um recurso aceitar token emitido para outro. Cada um é o enviado entregando a carta a quem não devia.
A operação segura inverte cada erro: redirect exato e pré-registrado, access token curto com refresh rotativo, validação de assinatura, emissor e audiência em todo recurso, e revogação central quando algo dá errado. Delegar poder ao enviado é eficiente e correto, desde que o mandato seja estreito, curto e verificável, e que a carta só valha nas mãos certas.
OAuth 2.0 e OIDC fazem o enviado agir com a autoridade de quem o enviou, sem receber a chave inteira: OAuth concede acesso por escopo, OIDC prova identidade, e o Authorization Code com PKCE garante que a carta só valha nas mãos certas. Okta, Auth0 e Keycloak são o instrumento; RFC 6749, OIDC e PKCE são a lei. A IA revisa escopo, detecta o antipadrão e testa os cantos, mas desenhar um mandato estreito e verificável continua sendo trabalho de arquitetura.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Segurançaבְּרִית
Federar identidade é uma aliança: um sistema confia na afirmação de quem o outro é. Entenda IdP e SP, a asserção assinada, o SSO que isso destrava e onde SAML ainda vence o OIDC.
Segurançaצֹאנֶךָ
O que é identidade, a diferença entre provar quem você é e decidir o que você pode, o ciclo joiner-mover-leaver, por que o acesso acumula e como sustentar IAM por código com trilha.
