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.
Ping IdentityDecodificador 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.
Ping IdentityDecodificador 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.
Ping IdentityExplicador de filtros LDAP
Cole um filtro de busca LDAP - receba a árvore anotada: operadores, tipos de correspondência, escapes RFC 4515 decodificados, OIDs de regras do AD reconhecidos, e erros ancorados no caractere exato.
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.
Ping IdentityGerador 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.
Ping IdentitySeletor de fluxo OAuth
Que tipo de app, existe usuário, precisa de acesso offline - e o grant certo volta com citação de RFC, com implicit e ROPC aposentados pelo nome conforme a RFC 9700.
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.
Ping Identity
Artigos
Anatomia de um JSON Web Token
Os três segmentos de um JWT, como a assinatura garante a confiança no token e por que decodificar um token não é a mesma coisa 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.
LerComo verificar um JWT com um JWKS: do kid à assinatura
Verificar um token assinado é uma sequência curta e rigorosa: ler o header, achar no JWKS do provedor a chave cujo kid bate, confirmar o algoritmo e checar a assinatura. Cada passo tem uma armadilha clássica, e é abrindo mão desse rigor que acontecem os bypasses de verificação.
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.
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: como proteger 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.
LerComo validar 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.
LerComo provisionar 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.
LerFundamentos de LDAP: o modelo de diretório por trás dos sistemas de identidade
O Lightweight Directory Access Protocol a partir dos princípios: a árvore de entradas e seus distinguished names, a operação de bind que autentica, buscas com base, escopo e filtro, os grupos sobre os quais decisões de acesso se apoiam, e o transporte LDAPS - o vocabulário de trabalho que todo produto de identidade presume antes de a própria documentação fazer sentido.
LerKerberos e SPNEGO: como o SSO silencioso de desktop realmente funciona
A maquinaria de tickets por trás do login sem prompt: os dois serviços do KDC, o TGT e o service ticket, por que SPNs e keytabs existem, como o SPNEGO carrega um ticket Kerberos dentro de um cabeçalho HTTP Negotiate, e a pequena lista de coisas - relógio fora de sincronia, SPN faltando, confiança do navegador - que quebram tudo na prática.
LerSCIM: o padrão que provisiona as contas que o SSO autentica
O System for Cross-domain Identity Management de uma sentada: por que o provisionamento precisava de um padrão, os esquemas de Users e Groups da RFC 7643, o protocolo REST da RFC 7644 - criar, filtrar, PATCH, desativar - e onde o SCIM se encaixa ao lado de SAML e OIDC numa arquitetura de identidade: eles autenticam a conta; o SCIM é como a conta chegou lá.
LerO modelo de políticas do PingAccess: gateway, agente e a pilha de regras
Como o PingAccess decide quem alcança o quê: as duas formas de implantação (gateway roteando para sites, agentes falando PAAP com um servidor de políticas), a partição em aplicações e recursos, regras compostas em conjuntos e grupos de conjuntos, a ordem fixa de avaliação, e a mediação de tokens que mantém backends legados no jogo.
LerA plataforma PingDirectory: armazenar, agregar, sincronizar, delegar
A plataforma de dados de identidade em quatro peças: o servidor PingDirectory como armazém LDAP de alta performance com REST SCIM 2.0 nativo, o PingDirectoryProxy como gateway LDAPv3 e diretório virtual, o PingDataSync como motor de sincronização bidirecional em tempo real entre armazéns heterogêneos, e o Delegated Admin como superfície controlada de autosserviço - mais a gramática operacional de cn=config, grupos de servidores e movimentos sem downtime.
LerPingOne: a plataforma atrás dos nomes de produto
O que o PingOne de fato é - uma plataforma multi-tenant de identidade como serviço organizada em ambientes dentro de uma organização - e como seus serviços nomeados (SSO, MFA, Protect, Verify, Authorize, DaVinci) dividem o trabalho, como ela se relaciona com a pilha autogerenciada PingFederate/PingAccess/PingDirectory e com o Advanced Identity Cloud, e por que a mesma palavra aparece em tantos nomes de produto.
LerPingOne DaVinci: orquestração de identidade como uma tela
O que é orquestração de identidade e por que virou categoria própria de produto: os fluxos de arrastar e soltar do DaVinci, o catálogo de conectores que transforma fornecedores em nós, a orquestração dirigida pelo servidor que deixa jornadas mudarem sem release de app, a origem na Singular Key, e como o DaVinci coexiste com as jornadas e árvores de herança ForgeRock sob uma família única de SDKs.
LerDe Sun a Ping: a linhagem ForgeRock decodificada
Por que o catálogo Ping tem dois de tudo: a árvore genealógica do OpenSSO, OpenDS e OpenIDM da Sun, passando por OpenAM, OpenDJ, OpenIDM e OpenIG da ForgeRock, até os atuais PingAM, PingDS, PingIDM, PingGateway e PingOne Advanced Identity Cloud - a fusão de 2023 que criou as pilhas paralelas, qual produto responde por qual nome, e como ler qualquer diagrama de arquitetura Ping sem ambiguidade.
LerRADIUS de ponta a ponta: um login 802.1X, pacote por pacote
O que um switch e um servidor RADIUS de fato dizem um ao outro quando um notebook é ligado na rede: os campos e códigos de pacote da RFC 2865, os atributos que carregam a identidade e a política, a conversa EAP repassada em atributos EAP-Message, a atribuição de VLAN da RFC 3580, os registros Start e Stop da RFC 2866, o Change of Authorization iniciado pelo servidor da RFC 5176, a cadeia de proxies e as duas coisas que o segredo compartilhado protege e não protege. Cada número vem da RFC em que está.
LerTACACS+ na administração de equipamentos: um login e um comando, troca a troca
Como um roteador pergunta a um servidor se um engenheiro pode fazer login, se o comando que ele acabou de digitar pode rodar, e como registra que o comando rodou: os três tipos de pacote da RFC 8907, o header de 12 bytes, o START, o REPLY e o CONTINUE da autenticação, a autorização comando a comando com argumentos nome=valor, o START, o STOP e o WATCHDOG do accounting, a ofuscação que a RFC se recusa a chamar de criptografia, o ancestral de 1993 descrito na RFC 1492 e a disciplina da method list, que mantém os equipamentos acessíveis quando os servidores não estão.
Ler802.1X e os métodos EAP: a porta, o envelope e a escolha que define a segurança
Controle de acesso à rede baseado em porta, a partir do frame: o supplicant, o authenticator e o servidor, o EAPOL e a porta controlada, os quatro códigos EAP da RFC 3748 e, por fim, a decisão que realmente importa: qual método roda dentro do envelope. EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM e EAP-AKA comparados pelo que cada um usa para autenticar, pelo que protege e pelo que exige no cliente, além da única configuração que anula a maioria deles, da atribuição de VLAN que o servidor devolve e das alternativas para os dispositivos que não conseguem fazer nada disso.
LerNTLM explicado: três mensagens, três versões e por que ele ainda está na sua rede
O que o NT LAN Manager de fato é, a partir da especificação da própria Microsoft: um desafio-resposta carregado dentro de outros protocolos, em mensagens NEGOTIATE, CHALLENGE e AUTHENTICATE que começam com a assinatura NTLMSSP; as variantes orientada a conexão e sem conexão; as versões LM, NTLMv1 e NTLMv2 que compartilham um fluxo e diferem na função de resposta; como reconhecê-lo num cabeçalho HTTP; por que sobrevive onde o Kerberos não alcança; o que pass-the-hash e retransmissão significam para ele; e como descobrir o que ainda depende dele antes de desligá-lo.
LerAutenticação web e portais cativos: a terceira porta para dentro de uma porta autenticada
Como um switch ou uma controladora faz o login de uma pessoa cujo dispositivo não consegue fazer 802.1X: o web authentication proxy do guia de switches da Cisco, a sessão HTTP interceptada e a página de login, a política baixada no sucesso, as páginas de falha e de expiração e a lista de observação, a detecção de hosts por ARP e DHCP snooping, autenticação web local contra central, o limite do HTTPS que está quebrando a interceptação em todo lugar e a substituição do truque pelo IETF, a arquitetura de portal cativo da RFC 8952 e as opções de DHCP e de anúncio de roteador da RFC 8910 que avisam ao dispositivo que um portal existe em vez de forjar respostas.
Ler