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 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.
LerInstalando o PingFederate: Requisitos, Primeira Execução e o Assistente de Configuração
O que uma implantação de PingFederate precisa antes mesmo de extrair o ZIP - um Java suportado, o plano de portas 9999/9031, uma conta de serviço dedicada - depois a instalação em si no Windows ou Linux, e exatamente o que o assistente de configuração inicial pede no primeiro login: licença, primeiro administrador e a base URL em que os parceiros vão confiar.
LerAtualizando o PingFederate: O Utilitário, o Merge e a Ordem no Cluster
Como upgrades de PingFederate realmente funcionam: o Upgrade Utility que copia a configuração da instalação antiga para a nova, as release notes que se leem para cada versão cruzada, o merge da configuração de log que todo mundo esquece, e a ordem console-primeiro que mantém o cluster consistente.
LerOs Arquivos de Inicialização do PingFederate: Quem Controla o Quê
Um tour pelos arquivos que decidem como um servidor PingFederate roda: os lançadores run.sh/run.bat, o run.properties para portas e papel no cluster, o jvm-memory.options para a heap, e o log4j2.xml para o que se escreve onde - mais o hábito de saber qual arquivo é dono de qual comportamento antes de precisar disso às 3 da manhã.
LerQuem Administra o PingFederate: Contas Nativas, Papéis e Login do Console via LDAP
O modelo de acesso administrativo: contas nativas e o conjunto de papéis que divide o poder - User Admin, Admin, Expression Admin, Auditor e o papel criptográfico - mais como a autenticação do console migra de contas nativas para um diretório LDAP via run.properties e ldap.properties, com grupos do diretório mapeados nos mesmos papéis.
LerHigiene Operacional do PingFederate: Licença, Notificações e o Arquivo de Configuração
Três hábitos que mantêm uma implantação de PingFederate entediante do melhor jeito: gerir o arquivo de licença e sua expiração, ligar os notification publishers para que eventos de certificado e de licenciamento se anunciem sozinhos, e tratar o arquivo de configuração data.zip - exportações manuais e os snapshots automáticos - como o mecanismo de backup, migração e desfazer que ele é.
LerO Mapa de Endpoints do PingFederate: Porta Admin, Porta de Runtime e o Que Mora Onde
Todo endpoint do PingFederate pertence a uma de duas famílias: endpoints administrativos na porta do console (o console e a /pf-admin-api) ou endpoints de runtime na porta do motor (os endpoints de aplicação /idp e /sp, o servidor de autorização OAuth /as, o userinfo e o discovery do OIDC, e o /pf/heartbeat.ping que os balanceadores vigiam). Saber qual porta responde qual caminho é metade do diagnóstico.
LerData Stores do PingFederate: LDAP e JDBC, Definidos Uma Vez, Usados em Todo Lugar
Data stores são as definições de conexão reutilizáveis do PingFederate: um store LDAP com tipo de diretório, hosts de failover, credenciais de bind e LDAPS; um store JDBC com sua URL de conexão, validation query e o driver JAR que precisa ser implantado antes de qualquer coisa conectar. Validadores de credencial, lookups de atributos e provisionamento consomem as mesmas definições - que é exatamente o ponto.
LerComo Usuários Provam Quem São: PCVs e os Cinco Adapters
O kit de autenticação do PingFederate que o exame nomeia: Password Credential Validators como a camada reutilizável de verificação de senha, e então os cinco adapters e o padrão de integração que cada um encarna - HTML Form para login interativo, HTTP Basic para o desafio 401, Kerberos para SSO silencioso de desktop, OpenToken para o handoff via integration kit e Reference ID para o back-channel sem agente.
LerOs Arquivos de Log do PingFederate: Qual Responde Qual Pergunta
O elenco de <pf_install>/pingfederate/log e para que serve cada membro: server.log para a aplicação, admin.log e admin-api.log para quem mudou o quê, transaction.log para resumos de transações de protocolo, audit.log para eventos de autenticação e segurança - mais os níveis do log4j2.xml que controlam verbosidade e o hábito de casar a pergunta com o arquivo.
LerPolíticas de Autenticação do PingFederate: Árvores, Seletores e o Contrato no Fim
Como o PingFederate decide quem autentica como: árvores de política cujos nós são fontes de autenticação e seletores, ramos Fail e Success fluindo de cima para baixo, fragmentos reutilizáveis para sequências comuns, e o Authentication Policy Contract no fim de todo caminho bem-sucedido - a camada de normalização que torna tudo rio abaixo independente da fonte.
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.
Ler