OAuth 2.0, PKCE, JWT, JWK e JWKS: entender seus papéis

OAuth 2.0, PKCE, JWT, JWK e JWKS aparecem frequentemente na mesma arquitetura, mas não são equivalentes. Alguns termos descrevem fluxos de autorização; outros, um formato de token ou uma forma de representar chaves criptográficas.

OAuth 2.0 organiza a autorização

OAuth 2.0 é um framework de autorização delegada. Ele permite que uma aplicação obtenha acesso limitado sem pedir ao usuário a senha de outro serviço.

OAuth não exige que todo access token seja um JWT. O formato do token é uma decisão separada.

PKCE protege a troca do código de autorização

PKCE adiciona uma prova temporária ao fluxo Authorization Code. O cliente cria um code_verifier aleatório e envia uma challenge derivada. Ao trocar o código recebido, precisa apresentar o verifier original.

O gerador PKCE ajuda a visualizar verifier, challenge e a transformação S256.

PKCE não criptografa um JWT nem substitui TLS. Ele protege uma etapa específica do fluxo de autorização.

JWT é um formato de token

JWT define uma estrutura compacta formada por segmentos separados por pontos. JWTs assinados podem carregar claims e uma assinatura verificável.

O inspetor JWT, o decodificador JWT e o codificador JWT facilitam a análise.

Decodificar um JWT não é o mesmo que verificar sua assinatura. O payload de um JWT normal não deve ser tratado como confidencial apenas por estar codificado.

JWK e JWKS representam chaves

JWK é uma representação JSON de uma chave criptográfica. Um JWKS é um conjunto de JWK, frequentemente publicado para que clientes obtenham as chaves públicas necessárias à verificação.

O inspetor JWK/JWKS ajuda a examinar tipo, identificadores e parâmetros.

Um cabeçalho JWT pode conter um kid, usado para selecionar a chave correspondente no JWKS.

Como as peças se encaixam

1. o cliente inicia OAuth e cria valores PKCE;
2. o servidor de autorização autentica o usuário e retorna um código;
3. o cliente troca esse código apresentando o verifier;
4. o servidor retorna tokens, que podem incluir JWTs;
5. o destinatário lê o cabeçalho e seleciona uma chave do JWKS;
6. verifica a assinatura e aplica issuer, audience, expiração e outras regras.

Confusões comuns

• OAuth não é formato de token.
• PKCE não é criptografia.
• Payloads JWT não são automaticamente confidenciais.
• Decodificar não é verificar uma assinatura.
• JWKS é um conjunto de chaves, não uma lista de sessões.

O essencial é distinguir protocolo, contêiner e chaves.