JWT vs OAuth: Principais diferenças, como funcionam juntos e melhores práticas

Se você é novo em autenticação e está criando um app que gerencia logins, pagamentos ou dados de usuários, provavelmente já se deparou com os termos JWT e OAuth. Eles podem parecer tópicos complexos e "só para backend", mas não são exclusivos para engenheiros de segurança.

Com APIs, integrações de terceiros e tecnologias emergentes como IA, MCP e sistemas baseados em agentes, esses dois exercem um papel direto na usabilidade, segurança e crescimento do seu produto. Compreender o básico significa que você pode:

• Desenvolver recursos seguros desde o início
• Comunicar-se de forma eficaz com sua equipe de engenharia
• Tomar melhores decisões de produto sobre autenticação e fluxos de usuários
• Evitar erros de segurança caros que prejudicam a confiança dos usuários

Por exemplo, na mais recente especificação MCP, o sistema de autorização é baseado em padrões consolidados:

• OAuth 2.1 IETF Draft (draft-ietf-oauth-v2-1-13)
• OAuth 2.0 Authorization Server Metadata (RFC8414)
• OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)
• OAuth 2.0 Protected Resource Metadata (RFC9728)

Por que isso importa#

Mesmo que você nunca escreva código de backend:

• Desenvolvedores aprendem como proteger APIs, gerenciar sessões e integrar serviços de terceiros.
• Gerentes de produto adquirem vocabulário para discutir fluxos de login, integrações e conformidade com equipes e parceiros.
• Fundadores e times em estágios iniciais evitam criar sistemas de login frágeis que quebram com integrações ou deixam você exposto a falhas de segurança.

JWT vs OAuth: Os dois conceitos principais#

JWT (JSON Web Token) e OAuth (Open Authorization) são frequentemente usados juntos, mas possuem propósitos diferentes.

Pense assim:

• OAuth é como você entrega as chaves para alguém, mas só para os cômodos aos quais ela tem permissão de entrar.
• JWT é o cartão de identificação que a pessoa carrega, prova de quem ela é e o que pode fazer.

Na próxima seção, vamos detalhar lado a lado para você ver claramente as diferenças e como eles se complementam.

O que é OAuth 2.0?#

OAuth 2.0 é um framework de autorização amplamente adotado que permite a uma aplicação (o cliente) acessar recursos de um usuário com permissões limitadas, sem precisar compartilhar as credenciais do usuário (como senhas).

Papéis principais no OAuth#

• Cliente: A aplicação que solicita acesso.
• Proprietário do recurso: Geralmente o usuário, que concede permissão.
• Servidor de autorização: Emite os tokens de acesso após a autorização.
• Servidor de recurso: Hospeda os recursos protegidos e valida os tokens

Tipos comuns de concessão OAuth (Fluxos)#

• Authorization Code Grant: Mais seguro e recomendado, especialmente com PKCE para apps web, SPA e móveis.
• Implicit Grant: Agora desencorajado no OAuth 2.1 por questões de segurança.
• Resource Owner Password Credentials (ROPC): Trocando nome de usuário e senha diretamente por tokens; menos seguro.
• Client Credentials Grant: Para comunicação servidor a servidor ou máquina a máquina.
• Device Flow: Para dispositivos sem teclado (ex: smart TVs), em que o usuário autoriza de um segundo dispositivo.

O que é JWT (JSON Web Token)?#

Um JWT é um padrão aberto (RFC 7519) para transmitir assertivas (claims) com segurança entre duas partes de forma compacta e compatível com URLs.

Estrutura de um JWT#

Um JWT consiste em três partes codificadas em base64url, separadas por pontos (.):

1. Header (Cabeçalho): Especifica o algoritmo (ex: HS256, RS256) e o tipo do token (JWT).
2. Payload (Corpo): Contém as claims, como:
   • iss (emissor)
   • sub (assunto, ex: ID do usuário)
   • aud (audiência)
   • exp (tempo de expiração)
   • Claims customizadas quando necessário
3. Signature (Assinatura) – Verifica que o token não foi adulterado.

Exemplo:

Um exemplo de JWT#

Aqui está um exemplo de um JWT típico em sua forma codificada, junto de sua estrutura decodificada para que você veja o que cada parte representa.

JWT Codificado (Base64URL)

É formado por três partes separadas por pontos: header.payload.signature

Estrutura Decodificada

• Header (Cabeçalho)

• Payload (Corpo)

O payload contém claims

• Signature (Assinatura)

A assinatura garante que o token não foi adulterado.

Principais características#

• Auto-contido: Todas as informações necessárias estão dentro do token.
• Sem estado: Não requer armazenamento de sessão no servidor.
• Assinado: (e opcionalmente criptografado) para garantir autenticidade.

JWT vs OAuth: Diferenças principais#

Resumindo:

• JWT é o recipiente: como um passaporte com dados de identidade.
• OAuth é o sistema: como o controle de imigração, decidindo quem recebe o passaporte e a quais áreas pode acessar.

Quando usar apenas JWT#

Use apenas JWT quando:

• Autenticação de sistema único em que sua aplicação emite e valida tokens sem envolver um provedor de identidade externo.
• Gerenciamento de sessão sem estado para validar a identidade do usuário sem armazenar dados de sessão no servidor.
• Autenticação simples de API para APIs internas que só precisam verificar direitos básicos de acesso sem consentimentos complexos.
• Validação orientada à performance para que servidores de recurso validem tokens localmente sem contato com o servidor de autenticação.

Exemplo:

Um app de página única e backend API próprio. A API emite um JWT com claims sub (ID do usuário), role e exp (expiração).

Quando usar apenas OAuth#

Use OAuth sem JWT quando:

• Não há necessidade de tokens auto-contidos e tokens opacos (que exigem consulta em servidor) são aceitáveis.
• Você deseja que o servidor de recurso sempre verifique com o servidor de autorização antes de conceder acesso.
• Você está em um ambiente legado ou regulado onde JWT não é adequado.
• O objetivo é autorização delegada, concedendo acesso limitado e seguro a apps de terceiros.

Exemplo:

Uma API que emite tokens de acesso opacos e valida cada requisição consultando o servidor de autorização.

Quando usar tanto JWT quanto OAuth#

Use os dois juntos quando:

• Você possui múltiplos serviços ou APIs e deseja OAuth para o fluxo seguro e JWT para tokens verificáveis entre serviços.
• Você oferece login de terceiros como "Entrar com Google", onde o OAuth cuida do consentimento e o JWT transporta o access token ou o ID token.
• Um cenário de microsserviços, onde cada serviço pode validar JWTs localmente.
• Você necessita de escalabilidade com o modelo de delegação do OAuth e a verificação sem estado do JWT.

Exemplo:

Seu app permite login com Google. O OAuth gerencia o processo de autorização, o Google emite um access token JWT e suas APIs o validam localmente antes de retornar dados.

Como JWT e OAuth funcionam juntos#

Em sistemas modernos de autenticação/autorização:

1. OAuth gerencia o fluxo de concessão de acesso.
2. O Servidor de Autorização emite um access token: frequentemente um JWT.
3. O JWT é enviado com requisições à API para provar identidade e permissões.

Tokens especiais no OAuth#

• ID token: Usado em OpenID Connect para provar a identidade do usuário; sempre um JWT.
• Access token: Pode ser JWT ou token opaco.

Melhores práticas ao usar JWTs e OAuth#

• Use HTTPS para proteger tokens em trânsito.
• Configure tempos curtos de expiração para JWTs; use refresh tokens para sessões mais longas.
  • https://auth.wiki/offline-access.
• Valide a assinatura antes de confiar em qualquer claim.
• Verifique o aud claim para garantir que o token se destina ao seu app.
• Evite armazenar tokens no localStorage se houver risco de XSS; prefira cookies seguros.

Considerações finais#

• OAuth 2.0 define como obter e utilizar tokens.
• JWT define como é o token e como transporta informações.
• Eles são complementares, não substitutos.

A maioria das APIs modernas usa OAuth para os fluxos de autorização e JWT para representação dos tokens. Compreender ambos ajudará você a desenvolver sistemas de autenticação seguros e escaláveis.