Categoria
Identità e token
Tutti gli strumenti e gli articoli di questa categoria, riuniti in un unico posto.
Strumenti
Decodificatore e verificatore di JWT
Decodifica l'header e i claim di un JSON Web Token, leggine la scadenza e i tempi in linguaggio chiaro e verifica una firma HS256/384/512 con un segreto incollato. Gira interamente nel tuo browser.
Ping IdentityDecodificatore OIDC
Incolla un ID token OpenID Connect o un documento .well-known/openid-configuration e decodificalo: i claim principali, i claim di profilo, gli endpoint e le capacità, con controlli sui claim richiesti, sull'algoritmo di firma, sul nonce e su PKCE.
Ping IdentityJWKS explainer + key matcher
Paste a JSON Web Key Set to break down every key, flag any private material, and match a JWT to its key by kid. Nothing leaves your browser.
Ping IdentityLDAP filter explainer
Paste an LDAP search filter - get the annotated tree: operators, match types, decoded RFC 4515 escapes, recognized AD matching-rule OIDs, and errors anchored to the exact character.
OAuth flow chooser
What kind of app, is there a user, offline access needed - and the right grant comes back RFC-cited, with implicit and ROPC retired by name per RFC 9700.
SAML Decoder
Paste a SAML Response or assertion (raw, base64, or URL-encoded) and decode its issuer, status, subject, conditions, audience, and attributes, with signature and weak-algorithm checks. Hardened against XXE.
Ping IdentityTOTP / HOTP Generator & Validator
Generate and check time-based (TOTP, RFC 6238) and counter-based (HOTP, RFC 4226) one-time passwords - the codes behind authenticator apps and hardware tokens such as FortiToken. SHA-1/256/512, configurable digits and step. Computed locally with Web Crypto; your secret never leaves your browser.
Ping IdentityVerificatore e challenge OAuth PKCE
Genera un code_verifier OAuth 2.0 e derivane il code_challenge S256, oppure incolla il tuo e verificalo rispetto alle regole di lunghezza e di set di caratteri di RFC 7636. La stessa derivazione SHA-256 in base64url che il tuo authorization server si aspetta. Gira interamente nel tuo browser.
Ping Identity
Articoli
Anatomia di un JSON Web Token
I tre segmenti di un JWT, come la firma lo rende affidabile e perché decodificare un token non è la stessa cosa che verificarlo.
LeggiJWKS and Key Rotation: How Providers Publish Their Keys
A JWKS is the public phone book of signing keys that an identity provider publishes so anyone can verify its tokens. Understanding the keys array, the kid that names each key, and why a provider keeps more than one key at a time is the foundation of token verification.
LeggiOpenID Connect: An Identity Layer on OAuth 2.0
What OpenID Connect adds to OAuth 2.0, the ID token at the center of it, the relying party and provider roles, how the authorization code flow delivers an ID token, and why an ID token is just a JWT you can decode and read.
LeggiAlgoritmi di firma JWT: HMAC, RSA ed ECDSA
Perché l'intestazione alg di un JWT conta, la differenza tra firma simmetrica e asimmetrica e come scegliere.
LeggiJWK Key Types: RSA, EC, OKP, and oct
Every JSON Web Key declares a kty, and that one field decides which parameters the key carries. Four types cover almost everything you will meet: RSA, elliptic curve, the Edwards and Montgomery curves, and the symmetric octet sequence. The crucial split in all of them is public versus private.
LeggiThe ID Token Claims, and What a Relying Party Checks
The claims inside an OIDC ID token: the required iss, sub, aud, exp, and iat; the nonce that stops replay; azp when there are multiple audiences; acr and amr for authentication strength; auth_time; and the at_hash and c_hash binding claims, with the validation a relying party performs on each.
LeggiOIDC vs OAuth 2.0: Authentication vs Authorization
Why OAuth 2.0 is about authorization and OpenID Connect is about authentication, the difference between an access token and an ID token, why using plain OAuth as a login mechanism is a known antipattern, and how to tell which token is which.
LeggiTrappole di sicurezza dei JWT: alg:none, confusione di chiave e controlli mancanti
La manciata di errori che trasforma un verificatore di JWT in una macchina per falsificazioni, e la validazione che un verificatore corretto deve eseguire.
LeggiVerifying a JWT with a JWKS: From kid to Signature
Verifying a signed token is a short, strict sequence: read the header, find the key whose kid matches in the provider's JWKS, confirm the algorithm, and check the signature. Each step has a classic pitfall, and skipping the strictness is how verification bypasses happen.
LeggiJWK Parameters and Thumbprints
A JWK is a JSON object describing one key, and its parameters say what the key is for and how to identify it. Beyond the key material, kid names it and an RFC 7638 thumbprint gives it a stable, computed identifier. This covers the common parameters and how a thumbprint is derived and used.
LeggiOIDC Discovery: The openid-configuration Document
How the .well-known/openid-configuration document lets a relying party learn a provider's endpoints and capabilities automatically, what the issuer, jwks_uri, and signing-algorithm fields mean, why advertising the none algorithm is dangerous, and why PKCE S256 support matters.
LeggiToken di accesso, token di aggiornamento e token ID
Tre token di OAuth e OpenID Connect che vengono costantemente confusi, a cosa serve davvero ciascuno e perché inviare quello sbagliato nel posto sbagliato è un bug reale.
LeggiClient pubblici vs confidenziali, e dove si inserisce PKCE
Se un client OAuth può custodire un segreto decide il suo intero modello di sicurezza. Perché le SPA e le app mobili sono client pubblici, e perché PKCE è ora raccomandato per tutti loro.
LeggiJWT Algorithm Confusion Attacks
Two classic JWT verification failures come from trusting the token's own algorithm header: accepting alg none, and being tricked into verifying an RS256 token as HS256 using the public key as the secret. Both are defeated by pinning the expected algorithm on the server instead of reading it from the token.
LeggiThe OIDC Authorization Code Flow
The authorization code flow is the recommended way an app gets an ID token: the user is redirected to the identity provider to log in, the app receives a short-lived code, and it exchanges that code at a back-channel token endpoint for the tokens. Keeping the token out of the browser is the whole point.
LeggiIl flusso di codice di autorizzazione OAuth 2.0
I quattro ruoli, la danza di reindirizzamento e scambio, e perché il codice viene scambiato per un token sul canale posteriore.
LeggiPKCE: proteggere il flusso di codice di autorizzazione OAuth
L'attacco di intercettazione che PKCE sconfigge, come il verifier e la challenge si incastrano, e perché S256 è obbligatorio.
LeggiOpenID Connect: identità sopra OAuth 2.0
Come OIDC aggiunge l'autenticazione all'autorizzazione di OAuth, cos'è il token ID e perché il flusso di codice con PKCE è il percorso raccomandato.
LeggiHow TOTP and HOTP one-time passwords work
Both turn a shared secret into a short code that proves possession without sending the secret. HOTP counts events; TOTP counts time. The engine underneath is the same HMAC plus a truncation step.
LeggiValidating one-time passwords: drift, windows, and replay
Generating a code is the easy half. Accepting one means tolerating clock drift, bounding the window, rejecting reuse, and throttling guesses, each a tradeoff between usability and security.
LeggiProvisioning Authenticators: otpauth URIs and QR Codes
Before an authenticator app can generate codes, it needs the shared secret and the parameters that go with it. That is carried in an otpauth URI, usually shown as a QR code to scan. Knowing the URI's fields explains what the QR code actually contains and why the secret is in base32.
LeggiInstalling PingFederate: Requirements, First Run, and the Setup Wizard
What a PingFederate deployment needs before the ZIP is even extracted - a supported Java runtime, the 9999/9031 port plan, a dedicated service account - then the install itself on Windows or Linux, and exactly what the initial configuration wizard asks of you on first login: license, first administrator, and the base URL partners will trust.
LeggiUpgrading PingFederate: The Utility, the Merge, and the Cluster Order
How PingFederate upgrades actually work: the Upgrade Utility that copies configuration from the old install into the new one, the release notes you read for every version crossed, the custom-logging merge everyone forgets, and the console-first order that keeps a cluster consistent.
LeggiThe PingFederate Startup Files: Who Controls What
A tour of the files that decide how a PingFederate server runs: the run.sh/run.bat launchers, run.properties for ports and the clustered role, jvm-memory.options for the heap, and log4j2.xml for what gets written where - plus the habit of knowing which file owns which behavior before you need it at 3 a.m.
LeggiWho Administers PingFederate: Native Accounts, Roles, and Console Login via LDAP
The administrative access model: native accounts and the role set that divides power - User Admin, Admin, Expression Admin, Auditor, and the cryptographic role - plus how console authentication moves from native accounts to an LDAP directory through run.properties and ldap.properties, with directory groups mapped onto the same roles.
LeggiPingFederate Operational Hygiene: License, Notifications, and the Configuration Archive
Three habits that keep a PingFederate deployment boring in the best way: managing the license file and its expiry, wiring notification publishers so certificate and licensing events announce themselves, and treating the data.zip configuration archive - manual exports and the automatic snapshots - as the backup, migration, and undo mechanism it is.
LeggiThe PingFederate Endpoints Map: Admin Port, Runtime Port, and What Lives Where
Every PingFederate endpoint belongs to one of two families: administrative endpoints on the console port (the console app and the /pf-admin-api) or runtime endpoints on the engine port (/idp and /sp application endpoints, the /as OAuth authorization server, OIDC's userinfo and discovery, and the /pf/heartbeat.ping that load balancers watch). Knowing which port answers which path is half the troubleshooting.
LeggiPingFederate Data Stores: LDAP and JDBC, Defined Once, Used Everywhere
Data stores are PingFederate's reusable connection definitions: an LDAP store with directory type, failover hosts, bind credentials, and LDAPS; a JDBC store with its connection URL, validation query, and the driver JAR that must be deployed before anything connects. Credential validators, attribute lookups, and provisioning all consume the same definitions - which is the whole point.
LeggiHow Users Prove Who They Are: PCVs and the Five Adapters
The PingFederate authentication toolkit the exam names: Password Credential Validators as the reusable password-checking layer, then the five adapters and the integration pattern each one embodies - HTML Form for interactive login, HTTP Basic for the 401 challenge, Kerberos for silent desktop SSO, OpenToken for integration-kit handoff, and Reference ID for the agentless back-channel.
LeggiThe PingFederate Log Files: Which One Answers Which Question
The cast of <pf_install>/pingfederate/log and what each member is for: server.log for the application, admin.log and admin-api.log for who changed what, transaction.log for runtime protocol summaries, audit.log for authentication and security events - plus the log4j2.xml levels that control verbosity and the habit of matching the question to the file.
LeggiPingFederate Authentication Policies: Trees, Selectors, and the Contract at the End
How PingFederate decides who authenticates how: policy trees whose nodes are authentication sources and selectors, Fail and Success branches flowing top-down, reusable fragments for common sequences, and the Authentication Policy Contract at the end of every successful path - the normalization layer that makes everything downstream source-independent.
LeggiLDAP Fundamentals: The Directory Model Behind Identity Systems
The Lightweight Directory Access Protocol from first principles: the tree of entries and their distinguished names, the bind operation that authenticates, searches with base, scope, and filter, the group memberships access decisions ride on, and the LDAPS transport - the working vocabulary every identity product assumes before its own documentation makes sense.
LeggiKerberos and SPNEGO: How Silent Desktop SSO Actually Works
The ticket machinery behind login-without-a-prompt: the KDC's two services, the TGT and the service ticket, why SPNs and keytabs exist, how SPNEGO carries a Kerberos ticket inside an HTTP Negotiate header, and the small list of things - clock skew, missing SPNs, browser trust - that break it in practice.
LeggiSCIM: The Standard That Provisions the Accounts SSO Signs In
The System for Cross-domain Identity Management in one sitting: why provisioning needed a standard, the RFC 7643 schemas for Users and Groups, the RFC 7644 REST protocol - create, filter, PATCH, deactivate - and where SCIM sits next to SAML and OIDC in an identity architecture: they authenticate the account, SCIM is how the account got there.
LeggiThe PingAccess Policy Model: Gateway, Agent, and the Rule Stack
How PingAccess decides who reaches what: the two deployment shapes (gateway routing to sites, agents speaking PAAP to a policy server), the application-and-resource partition, rules composed into rule sets and rule set groups, the fixed evaluation order, and the token mediation that keeps legacy backends in the game.
LeggiThe PingDirectory Platform: Store, Aggregate, Sync, Delegate
The four-piece identity data platform: the PingDirectory server as a high-performance LDAP and native SCIM 2.0 REST store, PingDirectoryProxy as the LDAPv3 gateway and virtual directory, PingDataSync as the real-time bidirectional synchronization engine across heterogeneous stores, and Delegated Admin as the controlled self-service surface - plus the operational grammar of cn=config, server groups, and zero-downtime moves.
LeggiPingOne: The Platform Behind the Product Names
What PingOne actually is - a multi-tenant identity-as-a-service platform organized around environments inside an organization - and how its named services (SSO, MFA, Protect, Verify, Authorize, DaVinci) divide the work, how it relates to the self-managed PingFederate/PingAccess/PingDirectory stack and to Advanced Identity Cloud, and why the same word appears in so many product names.
LeggiPingOne DaVinci: Identity Orchestration as a Canvas
What identity orchestration is and why it became its own product category: DaVinci's drag-and-drop flows, the connector catalog that turns vendors into nodes, server-driven orchestration that lets journeys change without app releases, the Singular Key origin story, and how DaVinci coexists with the ForgeRock-heritage journeys and trees under one SDK family.
LeggiFrom Sun to Ping: The ForgeRock Lineage Decoded
Why the Ping catalog has two of everything: the family tree from Sun's OpenSSO, OpenDS, and OpenIDM through ForgeRock's OpenAM, OpenDJ, OpenIDM, and OpenIG to today's PingAM, PingDS, PingIDM, PingGateway, and PingOne Advanced Identity Cloud - the 2023 merger that created the parallel stacks, which product answers to which name, and how to read any Ping architecture diagram without ambiguity.
Leggi