Qual a diferenca entre OAuth 2.0 e OpenID Connect?

OAuth 2.0 e um framework de autorizacao: concede a uma aplicacao acesso limitado a recursos de um usuario sem expor sua senha. OpenID Connect e uma camada de autenticacao construida sobre o OAuth 2.0 que adiciona o ID Token (um JWT assinado) para provar quem e o usuario. Use OAuth para autorizar acesso e OIDC para fazer login e SSO.

Qual grant type devo usar hoje?

Para qualquer cliente com usuario presente (web apps, SPAs, apps mobile), use Authorization Code com PKCE. Para comunicacao maquina-a-maquina sem usuario, use Client Credentials. Para dispositivos sem teclado ou navegador, use o Device Authorization Grant. Evite Implicit e Resource Owner Password, que estao depreciados.

Por que o PKCE e importante?

O PKCE (RFC 7636) protege o fluxo Authorization Code contra interceptacao de codigo. O cliente gera um code_verifier secreto e envia seu hash no inicio do fluxo; mesmo que um atacante capture o code de autorizacao, ele nao consegue troca-lo por tokens sem o verifier. O OAuth 2.1 torna o PKCE obrigatorio para todos os clientes.

Por que Implicit e Resource Owner Password estao depreciados?

O Implicit entregava o access token na URL, expondo-o a logs, historico e scripts de terceiros, sem protecao contra interceptacao. O Resource Owner Password fazia a aplicacao coletar a senha do usuario, reintroduzindo o problema que o OAuth resolve e inviabilizando MFA e SSO. Ambos foram removidos pelo OAuth 2.1 e desaconselhados pela RFC 9700.

Como evitar roubo e vazamento de tokens?

Use TLS em todos os endpoints, tokens de vida curta com rotacao de refresh tokens, armazenamento seguro (cookies HttpOnly e Secure com padrao BFF), valide audiencia e escopo no Resource Server e adote vinculacao de token via mTLS ou DPoP, de forma que um token roubado nao funcione sem a chave do cliente legitimo.

O que muda com o OAuth 2.1?

O OAuth 2.1 consolida as melhores praticas em um unico documento: PKCE obrigatorio para todos os clientes, remocao dos fluxos Implicit e Resource Owner Password, proibicao de tokens em URLs, correspondencia exata de redirect_uri e orientacoes sobre rotacao de refresh tokens. Projetar diretamente conforme o OAuth 2.1 e hoje o caminho de menor risco.

Implementacao segura de OAuth 2.0 e OIDC

Guia tecnico de implementacao segura de OAuth 2.0 e OpenID Connect: papeis, grant types, PKCE, tokens, ataques comuns e as boas praticas de defesa hoje.

OAuth 2.0 e OpenID Connect tornaram-se a espinha dorsal da identidade digital moderna: do login com Google ao acesso de uma API por outra aplicacao, eles definem como autorizar e autenticar sem expor senhas. Implementa-los mal, porem, abre brechas que vao do sequestro de sessao ao vazamento de dados corporativos. Este guia explica os conceitos, os fluxos recomendados e as defesas que toda equipe de engenharia deve adotar.

OAuth 2.0 nao e autenticacao: e autorizacao delegada

O equivoco mais comum sobre o OAuth 2.0 (definido na RFC 6749) e trata-lo como um protocolo de login. Ele nao foi desenhado para isso. OAuth 2.0 resolve um problema diferente: como uma aplicacao (o client) obtem acesso limitado a recursos de um usuario hospedados em outro servico, sem que esse usuario precise compartilhar suas credenciais com a aplicacao. Em outras palavras, OAuth e um framework de autorizacao delegada.

O exemplo classico: um aplicativo de agenda quer ler seus eventos do Google Calendar. Em vez de voce entregar sua senha do Google ao app, o Google emite um token que concede ao app permissao para ler apenas a agenda, por tempo limitado, e que pode ser revogado a qualquer momento. A senha nunca sai do dominio do Google.

Quando o que voce realmente precisa e saber quem e o usuario que esta entrando, OAuth 2.0 puro e insuficiente e perigoso de improvisar. Para isso existe o OpenID Connect.

OpenID Connect: a camada de autenticacao sobre OAuth

O OpenID Connect (OIDC), especificado no OpenID Connect Core 1.0, e uma fina camada de identidade construida sobre o OAuth 2.0. Ele reaproveita os mesmos fluxos, mas acrescenta uma peca decisiva: o ID Token, um JWT assinado que afirma, de forma verificavel, quem e o usuario autenticado, quando isso aconteceu e por qual provedor.

A regra pratica e direta: se voce precisa autorizar acesso a recursos, use OAuth 2.0; se precisa autenticar usuarios (login, SSO), use OpenID Connect. Construir um sistema de login apenas com OAuth 2.0, inspecionando access tokens para "descobrir" o usuario, e uma das causas recorrentes de falhas de seguranca de identidade. O access token e destinado a uma API, nao ao cliente, e nao garante que foi emitido para a aplicacao que o esta lendo.

O OIDC ainda padroniza pecas que provedores de identidade implementavam de forma proprietaria: o endpoint UserInfo, o documento de descoberta (well-known configuration), as chaves publicas de verificacao (JWKS) e os scopes de identidade como openid, profile e email. Esse padrao e o que torna o login federado e o SSO entre diferentes fornecedores interoperaveis e auditaveis, em vez de uma colcha de retalhos especifica de cada provedor.

Os quatro papeis do protocolo

Entender OAuth comeca por entender quem faz o que. O framework define quatro papeis:

Resource Owner (dono do recurso): normalmente o usuario final, que detem os dados e concede a autorizacao.
Client (cliente): a aplicacao que deseja acessar os recursos em nome do usuario. Pode ser confidencial (um backend capaz de guardar segredos) ou publico (uma SPA ou app mobile, que nao consegue proteger um segredo).
Authorization Server (servidor de autorizacao): autentica o usuario, obtem seu consentimento e emite os tokens. E o coracao da confianca do sistema.
Resource Server (servidor de recursos): a API que hospeda os dados protegidos e valida os access tokens recebidos antes de responder.

Grant types: escolha o fluxo certo

O OAuth 2.0 define varios grant types (fluxos de concessao). A escolha errada e fonte direta de vulnerabilidades. A tabela abaixo resume os fluxos relevantes, seu uso recomendado e seu status segundo o OAuth 2.0 Security Best Current Practice (RFC 9700) e o OAuth 2.1.

Grant type	Uso tipico	Status
Authorization Code + PKCE	Web apps, SPAs, apps mobile e qualquer cliente com usuario presente	Recomendado (padrao)
Client Credentials	Comunicacao maquina-a-maquina, sem usuario (backend para API)	Recomendado
Device Authorization (Device Code)	Dispositivos sem navegador ou teclado (TVs, IoT, CLIs)	Recomendado
Refresh Token	Renovacao de access tokens sem reautenticar o usuario	Recomendado (com rotacao)
Implicit	Antigamente usado por SPAs	Depreciado
Resource Owner Password Credentials	Troca direta de usuario e senha por token	Depreciado

Authorization Code com PKCE: o padrao de hoje

O fluxo Authorization Code e o mais seguro para qualquer cliente que envolva um usuario humano. O navegador e redirecionado ao servidor de autorizacao, o usuario se autentica e consente, e o servidor devolve um code de curta duracao. O cliente troca esse code por tokens em uma chamada de servidor para servidor, fora do alcance do navegador.

O PKCE (Proof Key for Code Exchange, RFC 7636) reforca esse fluxo contra interceptacao de codigo. O cliente gera um segredo aleatorio (code_verifier), envia seu hash (code_challenge) no inicio do fluxo e apresenta o verifier original na troca do code. Mesmo que um atacante intercepte o code, ele nao consegue troca-lo sem o verifier. O OAuth 2.1 torna o PKCE obrigatorio para todos os clientes, inclusive confidenciais.

Client Credentials: maquina a maquina

Quando nao ha usuario envolvido (um servico chamando outro), o fluxo Client Credentials permite que o proprio cliente confidencial obtenha um token usando suas credenciais. E o fluxo correto para integracoes backend, jobs agendados e microsservicos. Como nao ha usuario, nao ha refresh token nem ID token: o cliente simplesmente reautentica quando o token expira.

Device Authorization Grant: telas sem teclado

Para dispositivos com entrada limitada — uma smart TV, um dispositivo IoT, uma ferramenta de linha de comando — o Device Authorization Grant exibe um codigo curto que o usuario digita em outro aparelho (celular ou computador) para autorizar. O dispositivo faz polling no servidor de autorizacao ate receber os tokens, sem nunca manipular a senha do usuario.

Por que Implicit e Password estao depreciados

Dois fluxos historicos foram banidos pelas boas praticas atuais:

Implicit Grant: entregava o access token diretamente na URL de redirecionamento (no fragmento). Isso expoe o token a historico do navegador, logs, cabecalhos Referer e scripts de terceiros, alem de nao oferecer protecao contra interceptacao. Foi substituido por Authorization Code + PKCE, que tambem funciona perfeitamente em SPAs.
Resource Owner Password Credentials (ROPC): a aplicacao coleta diretamente usuario e senha e os troca por token. Isso reintroduz exatamente o problema que o OAuth veio resolver — o cliente passa a ver a senha — alem de inviabilizar MFA, SSO e provedores de identidade externos. O RFC 9700 recomenda explicitamente nao usa-lo.

O OAuth 2.1 consolida essas decisoes: remove o Implicit e o ROPC, exige PKCE e proibe a entrega de tokens na URL.

Os tres tokens e seus papeis

Confundir tokens e outra fonte classica de erro. Sao tres artefatos distintos, com destinatarios e tempos de vida diferentes:

Access Token: credencial de curta duracao apresentada ao Resource Server para acessar a API. Deve ser tratado como opaco pelo cliente — quem o interpreta e a API. Vida curta, de minutos a poucas horas.
Refresh Token: credencial de vida mais longa usada para obter novos access tokens sem reautenticar o usuario. Por ser sensivel, exige armazenamento seguro e, idealmente, rotacao a cada uso.
ID Token: exclusivo do OpenID Connect. E um JWT assinado destinado ao cliente, contendo claims sobre o usuario (identificador, emissor, audiencia, horario de autenticacao). Nunca deve ser enviado a uma API como se fosse access token.

Riscos e ataques mais comuns

O OWASP e o RFC 9700 catalogam os vetores que mais derrubam implementacoes OAuth:

Roubo de token: tokens em logs, em armazenamento inseguro do navegador ou trafegando sem TLS podem ser capturados e reutilizados. Tokens sao credenciais — tratam-se como senhas.
CSRF no fluxo de autorizacao: sem o parametro state, um atacante pode forcar a vitima a completar um fluxo controlado por ele. O state deve ser aleatorio, ligado a sessao e validado no retorno.
Open redirect / redirect_uri aberto: se o servidor aceita qualquer redirect_uri ou faz correspondencia parcial, o code ou token pode ser desviado para um dominio do atacante. A validacao deve ser por correspondencia exata.
Interceptacao de codigo (code interception): em apps mobile, outro app malicioso pode capturar o code no redirecionamento. O PKCE neutraliza esse ataque ao exigir o verifier na troca.
Token leakage: vazamento via cabecalho Referer, mixup de servidores de autorizacao ou tokens em URLs. Mitigado por nunca usar fluxos baseados em fragmento e por vincular tokens ao cliente.
Scope creep: solicitar mais permissoes do que o necessario amplia o estrago de um token comprometido. O principio do menor privilegio vale tambem para escopos.

Boas praticas de implementacao segura

Reunindo as recomendacoes do RFC 9700, do OAuth 2.1 e do OWASP, as defesas essenciais sao:

PKCE sempre: use Authorization Code + PKCE em todos os clientes, publicos e confidenciais.
Valide o redirect_uri por correspondencia exata: registre URIs completas e rejeite qualquer divergencia. Nunca aceite wildcards arbitrarios.
Use e valide o parametro state: ele protege contra CSRF e ajuda a religar o fluxo a sessao do usuario.
Tokens curtos com rotacao de refresh: access tokens de vida curta e refresh tokens com rotacao (revogando o token anterior a cada uso) limitam a janela de abuso e detectam reutilizacao.
Audiencia e escopo minimos: emita tokens com a audience correta e apenas os escopos necessarios; valide audiencia e escopo no Resource Server.
Armazenamento seguro de token: evite expor tokens a JavaScript de terceiros; prefira cookies HttpOnly e Secure com backend mediador (padrao BFF) quando aplicavel.
Vinculacao do token ao cliente (mTLS / DPoP): tokens vinculados por mTLS ou por DPoP (Demonstrating Proof of Possession) deixam de ser bearer puros — um token roubado nao serve sem a chave do cliente legitimo.
TLS em tudo: nenhum endpoint de autorizacao, token ou recurso deve operar sem TLS.

OAuth 2.1: a consolidacao

O OAuth 2.1 nao e um protocolo novo, e sim a unificacao das melhores praticas acumuladas desde 2012 em um documento coerente. Suas decisoes centrais: PKCE obrigatorio, remocao do Implicit e do ROPC, proibicao de tokens em URLs, exigencia de correspondencia exata de redirect_uri e orientacoes claras sobre rotacao de refresh tokens. Para times que comecam hoje, projetar diretamente conforme o OAuth 2.1 e o caminho de menor risco e o que melhor envelhece.

Como a Decripte ajuda

Na Decripte, tratamos identidade como superficie critica de seguranca. Nossa atuacao em AppSec e gestao de identidade cobre desde a revisao de arquitetura de autenticacao e autorizacao — escolha de fluxos, validacao de tokens, configuracao de provedores OIDC — ate testes ofensivos contra implementacoes OAuth em busca de open redirects, falhas de PKCE e vazamento de tokens. Atendemos do MEI ao enterprise, de 1 a mais de 100 mil colaboradores, com o mesmo rigor tecnico.

Se voce esta projetando ou auditando login e integracoes de API, comece pelo nosso diagnostico: comece gratis e conheca os planos para proteger sua plataforma de ponta a ponta.

Referencias

RFC 6749 - The OAuth 2.0 Authorization Framework
RFC 7636 - Proof Key for Code Exchange (PKCE)
RFC 9700 - Best Current Practice for OAuth 2.0 Security
OpenID Connect Core 1.0
OWASP - OAuth 2.0 e API Security Cheat Sheets / Top 10
OAuth 2.1 Authorization Framework (draft)