OAuth 2.0 e OpenID Connect: Autenticação, Autorização e Tokens JWT

A integração segura entre aplicações web, interfaces de página única (SPAs), aplicativos móveis e APIs corporativas depende da separação clara entre duas perguntas fundamentais: "Quem é você?" (Autenticação) e "O que você tem permissão para fazer?" (Autorização).

Historicamente, a falta dessa clareza levou sistemas a adotarem práticas arriscadas, como exigir que o usuário digitasse suas senhas principais diretamente em aplicativos terceiros para que estes pudessem ler dados de calendários ou contatos. A consolidação dos padrões abertos OAuth 2.0 e OpenID Connect (OIDC), combinados com a estrutura de dados de JSON Web Tokens (JWT), padronizou a troca de credenciais na internet de maneira segura e auditável.

Autenticação versus Autorização: A Divisão dos Padrões

Embora frequentemente implementados em conjunto pela mesma infraestrutura de identidade, os dois protocolos possuem funções técnicas distintas:

graph BT
    OAuth["<b>OAUTH 2.0 (AUTORIZAÇÃO)</b><br/>• Pergunta: <i>O que o aplicativo pode acessar?</i><br/>• Emite: <b>Access Token</b> (Escopos, Permissões e Audiência)"]
    OIDC["<b>OPENID CONNECT / OIDC (AUTENTICAÇÃO)</b><br/>• Pergunta: <i>Quem é o usuário final?</i><br/>• Emite: <b>ID Token</b> (Perfil, Identificador, E-mail, Claims)"]

    OIDC -->|"Extensão de Identidade construída sobre"| OAuth

• OAuth 2.0 (RFC 6749): Protocolo focado estritamente na delegação de autorização. Ele permite que um aplicativo cliente receba uma permissão limitada para interagir com uma API em nome do usuário sem jamais ter contato com a senha da conta. O resultado dessa negociação é um Access Token.
• OpenID Connect (OIDC): Uma camada de identidade padronizada construída no topo do OAuth 2.0. Enquanto o OAuth original era agnóstico sobre a identidade da pessoa, o OIDC formaliza a autenticação e emite um ID Token, informando ao cliente dados do perfil autenticado (nome, e-mail, identificador universal).

O Fluxo de Autorização Moderno: Authorization Code com PKCE

Para aplicações modernas (como SPAs em Angular, React ou aplicativos em celulares) que não conseguem armazenar um segredo de cliente confidencial (client secret) sem expô-lo no código-fonte, o padrão mandatório da indústria é o Authorization Code Flow com PKCE (Proof Key for Code Exchange):

1. Criação do Verificador de Código: A aplicação cliente gera uma sequência aleatória criptográfica (Code Verifier) e calcula o seu hash (Code Challenge).
2. Redirecionamento ao Provedor: O usuário é redirecionado ao Servidor de Autorização enviando o Code Challenge.
3. Autenticação e Consentimento: O usuário realiza login com MFA e aceita os escopos solicitados (por exemplo, leitura de faturas).
4. Devolução do Código: O provedor redireciona de volta para a aplicação entregando um código de autorização temporário via parâmetro de URL.
5. Troca do Token com PKCE: O cliente envia o código recebido juntamente com o Code Verifier original em uma chamada POST segura de backend. O servidor de autorização valida o hash e emite os tokens finais, impedindo ataques de interceptação de código por softwares maliciosos instalados no mesmo dispositivo.

A Estrutura de um JSON Web Token (JWT)

O formato mais amplamente empregado para representar esses tokens é o JWT (RFC 7519). Ele consiste em uma cadeia de texto compacta codificada em Base64Url, dividida em três seções separadas por pontos:

[ HEADER ] . [ PAYLOAD ] . [ SIGNATURE ]

// 1. Header (Cabeçalho): define o algoritmo criptográfico de assinatura
{
  "alg": "RS256",
  "typ": "JWT"
}

// 2. Payload: as declarações de negócio (Claims) sobre o usuário e contexto
{
  "sub": "user_98741",
  "name": "Murilo Abreu",
  "email": "usuario@exemplo.com.br",
  "roles": ["EngenheiroDeSoftware", "Arquiteto"],
  "scope": "read:pedidos write:pedidos",
  "iss": "https://auth.exemplo.com.br/",
  "aud": "https://api.exemplo.com.br",
  "exp": 1789700000
}

A terceira parte, a Assinatura Digital, é calculada pelo servidor de autorização utilizando sua chave privada (geralmente através do algoritmo assimétrico RS256).

Validação Sem Estado (Stateless Validation)

A principal vantagem de engenharia do JWT é permitir a validação autônoma. Quando uma API de microsserviço recebe uma requisição contendo o cabeçalho Authorization: Bearer <token>, ela não precisa realizar uma consulta de banco de dados ou fazer chamadas remotas de rede para confirmar a sessão:

1. A API baixa e armazena em cache as chaves públicas do servidor de autorização via endpoint JWKS (JSON Web Key Set).
2. O servidor valida matematicamente a assinatura criptográfica do token usando a chave pública.
3. Se a assinatura for legítima e a data de expiração (exp) não foi ultrapassada, o microsserviço aceita as declarações (roles, user_id) como verdadeiras imediatamente.

Cuidados Críticos de Segurança com Tokens

Apesar de prático, o uso incorreto de tokens JWT pode introduzir riscos operacionais graves:

• Tokens de Acesso com Vida Curta: Como tokens JWT não podem ser facilmente revogados antes da sua expiração sem reintroduzir uma lista negra centralizada de banco de dados, os Access Tokens devem expirar em curtos intervalos (por exemplo, 10 a 15 minutos). A renovação contínua é feita através de Refresh Tokens protegidos com rotação obrigatória a cada uso.
• Armazenamento Seguro no Navegador: Evitar salvar tokens com privilégios de escrita no localStorage do navegador, visto que qualquer vulnerabilidade de Cross-Site Scripting (XSS) permite a leitura e roubo do token por scripts maliciosos. A melhor prática recomenda o uso de cookies com os sinalizadores HttpOnly, Secure e SameSite=Strict.
• Nunca Inserir Segredos no Payload: As informações contidas no payload do JWT não são criptografadas, mas apenas codificadas em Base64. Qualquer pessoa com o token consegue ler seu conteúdo textual instantaneamente; logo, senhas, chaves privadas ou dados sigilosos nunca devem compor as declarações de um token.