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

Se és novo em autenticação e estás a criar uma app que gere logins, pagamentos ou dados de utilizadores, provavelmente já te deparaste com os termos JWT e OAuth. Podem soar como temas complexos, "apenas de backend", mas não são só para engenheiros de segurança.

Com APIs, integrações de terceiros e tecnologias emergentes como IA, MCP e sistemas baseados em agentes, estes dois desempenham um papel direto na usabilidade, segurança e crescimento do teu produto. Compreender o básico permite-te:

• Conceber funcionalidades seguras desde o início
• Comunicar eficazmente com a tua equipa de engenharia
• Tomar melhores decisões de produto sobre autenticação e fluxos de utilizador
• Evitar erros de segurança dispendiosos que afetam a confiança dos utilizadores

Por exemplo, na mais recente spec MCP, o sistema de autorização baseia-se em normas comprovadas:

• Esboço IETF OAuth 2.1 (draft-ietf-oauth-v2-1-13)
• Metadados do Servidor de Autorização OAuth 2.0 (RFC8414)
• Protocolo de Registo Dinâmico de Clientes OAuth 2.0 (RFC7591)
• Metadados de Recursos Protegidos OAuth 2.0 (RFC9728)

Porque isto importa#

Mesmo que nunca escrevas código de backend:

• Os developers aprendem como proteger APIs, gerir sessões e integrar serviços de terceiros.
• Os gestores de produto ganham vocabulário para discutir fluxos de login, integrações e conformidade com equipas e parceiros.
• Fundadores e equipas em fase inicial evitam construir sistemas de login frágeis que falham com integrações ou ficam vulneráveis a violações.

JWT vs OAuth: Os dois conceitos principais#

JWT (JSON Web Token) e OAuth (Open Authorization) são frequentemente usados em conjunto, mas servem objetivos diferentes.

Pensa assim:

• OAuth é como dás as chaves a alguém, mas apenas para as divisões a que tem acesso.
• JWT é o cartão de identificação que transportam, prova de quem são e do que podem fazer.

Na próxima secção, vamos comparar lado a lado para veres claramente as diferenças e como se complementam.

O que é OAuth 2.0?#

OAuth 2.0 é uma framework de autorização amplamente adotada, que permite a uma aplicação (o cliente) aceder aos recursos de um utilizador com permissões limitadas, sem necessidade de partilhar as credenciais do utilizador (como passwords).

Papéis principais no OAuth#

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

Tipos de concessão comuns do OAuth (Fluxos)#

• Authorization Code Grant: O mais seguro e recomendado, especialmente com PKCE para apps no navegador, SPA e mobile.
• Implicit Grant: Agora desaconselhado no OAuth 2.1 por motivos de segurança.
• Resource Owner Password Credentials (ROPC): Troca diretamente username e password por tokens; menos seguro.
• Client Credentials Grant: Para comunicação servidor-servidor ou máquina a máquina.
• Device Flow: Para dispositivos sem teclado (por exemplo, smart TVs), onde o utilizador autoriza a partir de um segundo dispositivo.

O que é JWT (JSON Web Token)?#

Um JWT é um padrão aberto (RFC 7519) para transmitir de forma segura declarações entre duas partes de forma compacta e segura para URLs.

Estrutura de um JWT#

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

1. Header: Especifica o algoritmo (por exemplo, HS256, RS256) e o tipo de token (JWT).
2. Payload: Contém claims, como por exemplo:
   • iss (issuer/emissor)
   • sub (subject, por exemplo, ID do utilizador)
   • aud (audience/público)
   • exp (data de expiração)
   • Claims personalizadas, conforme necessário
3. Assinatura – Verifica se o token não foi adulterado.

Exemplo:

Um exemplo de JWT#

Aqui está um exemplo de um JWT típico na sua forma codificada, juntamente com a estrutura descodificada para veres o que cada parte representa.

JWT Codificado (Base64URL)

Isto é composto por três partes separadas por pontos: header.payload.signature

Estrutura descodificada

• Header

• Payload

O payload contém claims

• Assinatura

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

Características principais#

• Autónomo: Toda a informação necessária está dentro do token.
• Sem estado: Não é necessário armazenar sessão no servidor.
• Assinado: (e opcionalmente encriptado) para garantir autenticidade.

JWT vs OAuth: Diferenças principais#

Resumindo:

• JWT é o contentor: como um passaporte com dados de identificação.
• OAuth é o sistema: como o controlo de migração, decide quem recebe o passaporte e o que pode aceder.

Quando usar apenas JWT#

Usa apenas JWT quando:

• Autenticação de sistema único em que a tua app emite e verifica tokens sem envolver um fornecedor de identidade externo.
• Gestão de sessão sem estado para validar a identidade do utilizador sem guardar dados de sessão no servidor.
• Autenticação simples de API para APIs internas que só precisam de verificar direitos de acesso básicos sem fluxos de consentimento complexos.
• Validação focada na performance para que os servidores de recursos possam validar tokens localmente sem contactar o servidor de autenticação.

Exemplo:

Uma app de página única e API backend que possuis. A API emite um JWT contendo sub (ID de utilizador), role e exp (expiração).

Quando usar apenas OAuth#

Usa OAuth sem JWT quando:

• Não precisas de tokens autónomos, e tokens opacos que requerem consulta são aceitáveis.
• Queres que o servidor de recursos verifique sempre com o servidor de autorização antes de conceder acesso.
• Estás num ambiente legado ou regulado onde JWT não é apropriado.
• O objetivo é autorização delegada para conceder acesso limitado e seguro a apps de terceiros.

Exemplo:

Uma API que emite tokens de acesso opacos e valida cada pedido junto ao servidor de autorização.

Quando usar ambos JWT e OAuth#

Usa ambos quando:

• Tens múltiplos serviços ou APIs e queres OAuth para o fluxo seguro e JWT para tokens verificáveis entre serviços.
• Ofereces login de terceiros como "Iniciar sessão com Google" onde OAuth gere o consentimento e o JWT transporta o access ou ID token.
• Executas uma arquitetura de microserviços onde cada serviço pode validar JWTs localmente.
• Precisar de escalabilidade com o modelo de delegação do OAuth e a verificação sem estado do JWT.

Exemplo:

A tua app permite login com Google. OAuth gere o processo de autorização, o Google emite um access token em JWT, e as tuas APIs verificam-no localmente antes de devolver dados.

Como JWT e OAuth funcionam em conjunto#

Nos ambientes modernos de autenticação/autorização:

1. OAuth gere 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 os pedidos API para provar identidade e permissões.

Tokens especiais no OAuth#

• ID token: Usado no OpenID Connect para provar a identidade do utilizador; é sempre um JWT.
• Access token: Pode ser um JWT ou um token opaco.

Melhores práticas na utilização de JWTs e OAuth#

• Utiliza HTTPS para proteger os tokens em trânsito.
• Define tempos de expiração curtos para JWTs; usa refresh tokens para sessões longas.
  • https://auth.wiki/offline-access.
• Valida a assinatura antes de confiar em qualquer claim.
• Verifica o aud claim para garantir que o token se destina à tua app.
• Evita guardar tokens em localStorage se houver risco de XSS; prefere cookies seguros.

Considerações finais#

• OAuth 2.0 define como obter e usar tokens.
• JWT define como é o token e como transporta informação.
• São complementares, não intercambiáveis.

A maioria das APIs modernas usa OAuth para fluxos de autorização e JWT para representação de tokens. Perceber ambos vai ajudar-te a conceber sistemas de autenticação seguros e escaláveis.