Categoria
Identidade e tokens
Todas as ferramentas e artigos desta categoria, reunidos em um só lugar.
Ferramentas
Decodificador e verificador de JWT
Decodifique o cabeçalho e os claims de um JSON Web Token, leia sua expiração e seus tempos em linguagem clara e verifique uma assinatura HS256/384/512 com um segredo colado. Roda inteiramente no seu navegador.
Decodificador OIDC
Cole um ID token do OpenID Connect ou um documento .well-known/openid-configuration e decodifique: as claims principais, claims de perfil, endpoints e capacidades, com verificações de claims obrigatórias, algoritmo de assinatura, nonce e PKCE.
Decodificador SAML
Cole uma resposta ou asserção SAML (bruta, base64 ou URL-encoded) e decodifique emissor, status, sujeito, condições, audiência e atributos, com verificação de assinatura e de algoritmos fracos. Protegido contra XXE.
Explicador de JWKS + correspondência de chaves
Cole um JSON Web Key Set para detalhar cada chave, sinalizar qualquer material privado e corresponder um JWT à sua chave pelo kid. Nada sai do seu navegador.
Gerador e validador TOTP / HOTP
Gere e verifique senhas de uso único baseadas em tempo (TOTP, RFC 6238) e em contador (HOTP, RFC 4226) - os códigos por trás dos aplicativos autenticadores e de tokens físicos como o FortiToken. SHA-1/256/512, com dígitos e intervalo configuráveis. Tudo calculado localmente com Web Crypto; seu segredo nunca sai do navegador.
Verificador e challenge de OAuth PKCE
Gere um code_verifier de OAuth 2.0 e derive seu code_challenge S256, ou cole o seu e verifique-o com as regras de comprimento e de conjunto de caracteres do RFC 7636. A mesma derivação SHA-256 em base64url que o seu servidor de autorização espera. Roda inteiramente no seu navegador.
Artigos
Anatomia de um JSON Web Token
Os três segmentos de um JWT, como a assinatura o torna confiável e por que decodificar um token não é o mesmo que verificá-lo.
LerJWKS e Rotação de Chaves: Como os Provedores Publicam suas Chaves
Um JWKS é a lista pública de chaves de assinatura que um provedor de identidade publica para que qualquer um possa verificar seus tokens. Entender o array keys, o kid que nomeia cada chave e por que um provedor mantém mais de uma chave ao mesmo tempo é a base da verificação de tokens.
LerOpenID Connect: Uma Camada de Identidade sobre o OAuth 2.0
O que o OpenID Connect adiciona ao OAuth 2.0, o ID token no centro de tudo, os papéis de relying party e provedor, como o fluxo de código de autorização entrega um ID token, e por que um ID token é apenas um JWT que você pode decodificar e ler.
LerAlgoritmos de assinatura de JWT: HMAC, RSA e ECDSA
Por que o cabeçalho alg de um JWT importa, a diferença entre assinatura simétrica e assimétrica, e como escolher.
LerAs Claims do ID Token, e o Que uma Relying Party Verifica
As claims dentro de um ID token OIDC: as obrigatórias iss, sub, aud, exp e iat; o nonce que impede repetição; azp quando há múltiplas audiências; acr e amr para a força da autenticação; auth_time; e as claims de vínculo at_hash e c_hash, com a validação que uma relying party realiza em cada uma.
LerTipos de Chave JWK: RSA, EC, OKP e oct
Toda JSON Web Key declara um kty, e esse único campo decide quais parâmetros a chave carrega. Quatro tipos cobrem quase tudo o que você encontrará: RSA, curva elíptica, as curvas de Edwards e Montgomery, e a sequência de octetos simétrica. A divisão crucial em todos eles é público versus privado.
LerArmadilhas de segurança em JWT: alg:none, confusão de chave e verificações ausentes
O punhado de erros que transforma um verificador de JWT em uma máquina de falsificação, e a validação que um verificador correto deve fazer.
LerOIDC vs OAuth 2.0: Autenticação vs Autorização
Por que o OAuth 2.0 é sobre autorização e o OpenID Connect é sobre autenticação, a diferença entre um access token e um ID token, por que usar OAuth puro como mecanismo de login é um antipadrão conhecido, e como saber qual token é qual.
LerVerificando um JWT com um JWKS: do kid à Assinatura
Verificar um token assinado é uma sequência curta e rigorosa: ler o cabeçalho, encontrar a chave cujo kid corresponde no JWKS do provedor, confirmar o algoritmo e checar a assinatura. Cada passo tem uma armadilha clássica, e pular o rigor é como acontecem os bypasses de verificação.
LerOIDC Discovery: O Documento openid-configuration
Como o documento .well-known/openid-configuration permite a uma relying party descobrir automaticamente os endpoints e capacidades de um provedor, o que significam os campos issuer, jwks_uri e de algoritmo de assinatura, por que anunciar o algoritmo none é perigoso, e por que o suporte a PKCE S256 importa.
LerParâmetros e thumbprints de JWK
Uma JWK é um objeto JSON que descreve uma chave, e seus parâmetros dizem para que a chave serve e como identificá-la. Além do material da chave, kid a nomeia e um thumbprint (RFC 7638) dá a ela um identificador estável e computado. Este artigo cobre os parâmetros comuns e como um thumbprint é derivado e usado.
LerTokens de acesso, tokens de atualização e tokens de ID
Três tokens do OAuth e do OpenID Connect que vivem sendo confundidos, para que cada um de fato serve, e por que enviar o errado ao lugar errado é um bug de verdade.
LerAtaques de confusão de algoritmo em JWT
Duas falhas clássicas de verificação de JWT vêm de confiar no algoritmo declarado pelo próprio token: aceitar alg none, e ser enganado a verificar um token RS256 como HS256 usando a chave pública como segredo. Ambas são derrotadas fixando o algoritmo esperado no servidor em vez de lê-lo do token.
LerClientes públicos vs confidenciais, e onde o PKCE se encaixa
Se um cliente OAuth consegue guardar um segredo decide todo o seu modelo de segurança. Por que SPAs e apps móveis são clientes públicos, e por que o PKCE agora é recomendado para todos eles.
LerO fluxo authorization code do OIDC
O fluxo authorization code é a forma recomendada de um app obter um ID token: o usuário é redirecionado ao provedor de identidade para logar, o app recebe um código de curta duração, e o troca em um token endpoint de back-channel pelos tokens. Manter o token fora do navegador é o objetivo inteiro.
LerO fluxo de código de autorização do OAuth 2.0
Os quatro papéis, a dança de redirecionar e trocar, e por que o código é trocado por um token no canal de fundo.
LerPKCE: protegendo o fluxo de código de autorização do OAuth
O ataque de interceptação que o PKCE derrota, como o verificador e o desafio se encaixam, e por que o S256 é obrigatório.
LerOpenID Connect: identidade sobre o OAuth 2.0
Como o OIDC adiciona autenticação à autorização do OAuth, o que é o token de ID e por que o fluxo de código com PKCE é o caminho recomendado.
LerComo funcionam as senhas de uso único TOTP e HOTP
Ambas transformam um segredo compartilhado em um código curto que prova posse sem transmitir o segredo. O HOTP conta eventos; o TOTP conta tempo. O motor por baixo é o mesmo HMAC mais uma etapa de truncamento.
LerValidando senhas de uso único: desvio, janelas e repetição
Gerar um código é a metade fácil. Aceitar um exige tolerar o desvio de relógio, limitar a janela, rejeitar a reutilização e conter as tentativas, cada um um compromisso entre usabilidade e segurança.
LerProvisionando autenticadores: URIs otpauth e QR codes
Antes de um app autenticador poder gerar códigos, ele precisa do segredo compartilhado e dos parâmetros que o acompanham. Isso é carregado em uma URI otpauth, normalmente mostrada como um QR code para escanear. Conhecer os campos da URI explica o que o QR code de fato contém e por que o segredo está em base32.
Ler