ID Token versus Access Token: a diferença crucial no OpenID Connect

By Mirko Peters · 2026-10-28

Descubra as diferenças essenciais entre ID tokens e access tokens no OpenID Connect e entenda por que confundi-los cria falhas de segurança graves.

Automatically translated with AI from the original post. Read the English original

Entender a distinção entre ID token e access token é essencial para desenvolvedores e administradores de TI que trabalham com autenticação moderna. Enquanto o OAuth 2.0 cuida das permissões, o OpenID Connect introduz o ID token para confirmar a identidade do usuário. Confundir esses dois tokens distintos leva a vulnerabilidades de segurança críticas em aplicações na nuvem.

Principais conclusões

• ID tokens comprovam a identidade do usuário, enquanto access tokens concedem autorização e permissões.
• Confundir esses dois tokens é um erro frequente na segurança de aplicações desenvolvidas internamente.
• O OpenID Connect adiciona a confirmação de identidade por cima do framework OAuth 2.0.
• Access tokens podem ser revogados, o que oferece uma postura de segurança mais segura do que armazenar senhas.
• As aplicações devem verificar criptograficamente os ID tokens recebidos, em vez de confiar neles cegamente.

O dilema central: identidade versus autorização

Na evolução das aplicações web modernas, os desenvolvedores frequentemente se deparam com confusão sobre como os usuários fazem login e como esses mesmos usuários interagem com os dados subjacentes. Grande parte dessa confusão decorre da sobreposição de terminologia no campo de identidade. Quando as aplicações começaram a se expandir rapidamente pela web, depender apenas de combinações de nome de usuário e senha criou um enorme gargalo de segurança. Os usuários ficaram cansados de gerenciar dezenas de credenciais diferentes, o que levou à reutilização fraca de senhas em várias plataformas.

Para resolver parte desse problema, surgiu o OAuth 2.0. No entanto, o OAuth 2.0 nunca foi criado para responder quem é a pessoa. Seu propósito inteiro é fornecer autorizações, conhecidas como access tokens, que permitem a uma aplicação acessar endpoints de dados específicos em nome de um usuário. Um access token detalha o que uma aplicação pode fazer, mas permanece completamente silencioso sobre a identidade da pessoa que o possui. Essa lacuna fundamental significou que as empresas que tentavam criar experiências de login único precisavam acoplar suas próprias verificações de identidade personalizadas ao OAuth, resultando em implementações fragmentadas que raramente concordavam entre si.

O OpenID Connect preencheu exatamente essa lacuna ao introduzir uma camada padronizada, projetada especificamente para autenticação. Ao usar um segundo token junto com o access token tradicional, o OpenID Connect separa com clareza a questão da identidade da questão das permissões. Manter esses dois conceitos separados é a mudança de mentalidade mais importante para quem cria ou audita aplicações na nuvem hoje.

Anatomia do ID Token: o que há dentro

Quando um usuário clica no botão "Entrar com a Microsoft", o provedor de identidade processa as credenciais, lida com os requisitos de autenticação multifator e, por fim, redireciona o usuário para a aplicação acompanhado de um ID token. Esse token é empacotado como um JSON Web Token, comumente abreviado como JWT e pronunciado "jot". À primeira vista, um JWT parece uma string intimidante e impenetrável de caracteres separados por pontos. No entanto, sua estrutura interna é notavelmente simples depois de decodificada.

Dentro de um ID token, você encontrará um conjunto de declarações padrão, cada uma com uma finalidade bem definida:

• Emissor: Identifica o provedor de identidade específico (como o Microsoft Entra ID) que gerou e assinou o token.
• Subject (sub): Serve como um identificador único e imutável do usuário. Crucialmente, ele foi projetado para não mudar, mesmo que o usuário atualize o nome de exibição ou o endereço de e-mail.
• Audience (aud): Especifica o aplicativo exato para o qual o token foi criado, garantindo que um token destinado a um app não possa ser interceptado de forma maliciosa e reutilizado por outro.
• Timestamps: Indicam quando o token foi emitido, quando expira e o momento exato em que o usuário se autenticou.
• Nonce: Funciona como um número de recibo seguro que vincula o token resultante à sessão de login específica que iniciou a solicitação, bloqueando efetivamente ataques de repetição (replay).

Crucialmente, todo o pacote é assinado com a chave privada do provedor. O aplicativo receptor valida essa assinatura usando a chave pública correspondente, publicada pelo provedor. Sem essa verificação criptográfica, um ID token não passa de uma simples anotação não verificada trocada entre as partes.

O perigo de tratar identidade como acesso

Um dos antipadrões mais perigosos no desenvolvimento de aplicações é tratar um ID token como uma chave de permissão. Como um ID token confirma que o usuário é John Doe de uma organização específica, desenvolvedores inexperientes às vezes cometem o erro de usar essa confirmação para conceder direitos administrativos ou acesso irrestrito ao banco de dados. Isso representa um entendimento fundamentalmente equivocado da arquitetura.

Um ID token apenas informa quem está na porta de entrada; ele não diz se essa pessoa pode entrar em todos os cômodos internos ou clicar em um botão administrativo específico. A lógica de autorização deve ser tratada separadamente pela aplicação, usando controle de acesso baseado em funções (RBAC) ou mecanismos semelhantes, tomando a identidade verificada como ponto de partida, e não como a decisão final de autorização.

Além disso, as aplicações frequentemente cometem o erro de aceitar ID tokens recebidos sem executar as validações adequadas. Confiar cegamente em um token só porque uma biblioteca o processou nos bastidores deixa os sistemas expostos a dados forjados. Validar a assinatura, verificar os carimbos de expiração e conferir a declaração de audience são etapas indispensáveis para manter uma postura segura.

Conclusão

Dominar a fronteira entre identidade e autorização ajuda a desmistificar a arquitetura moderna de nuvem. Ao manter os ID tokens estritamente focados em comprovar quem está do outro lado do teclado, e deixar os access tokens definirem quais ações são permitidas, os desenvolvedores conseguem criar integrações robustas e seguras com plataformas como o Microsoft Entra ID. Para ouvir uma análise completa desses conceitos e entender como os fluxos modernos de login funcionam no ecossistema Microsoft, confira a discussão completa. Ouça o episódio completo e aprofunde-se hoje mesmo na mecânica da identidade em nuvem!

Perguntas frequentes

Um ID token pode ser usado para chamar APIs ou acessar recursos protegidos?

Não. Um ID token contém apenas declarações de identidade sobre quem é o usuário. Para chamar APIs ou acessar recursos protegidos, a aplicação deve usar um access token emitido via OAuth 2.0.

Por que o OpenID Connect e o OAuth 2.0 usam tokens separados?

Separar identidade de autorização permite que as aplicações verifiquem quem está fazendo login sem dar a elas permissão irrestrita para manipular os dados ou recursos subjacentes do usuário.

O que acontece se uma aplicação aceitar um ID token sem verificar sua assinatura?

Pular a verificação de assinatura deixa a aplicação vulnerável a tokens forjados, já que qualquer pessoa poderia gerar uma string personalizada alegando ser um usuário válido.

Onde o valor 'nonce' se encaixa na troca de tokens?

O nonce é uma string aleatória gerada no início do fluxo de login, incorporada dentro do ID token, que permite à aplicação prevenir ataques de repetição (replay).