Categorie
Identiteit & tokens
Alle hulpmiddelen en artikelen in deze categorie, op één plek verzameld.
Hulpmiddelen
JWKS 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 IdentityJWT-decoder en -verificateur
Decodeer de header en claims van een JSON Web Token, lees de vervaltijd en timing in gewone taal en verifieer een HS256/384/512-handtekening met een geplakt geheim. Draait volledig in je 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.
OAuth-PKCE-verificateur en -challenge
Genereer een OAuth 2.0-code_verifier en leid de S256-code_challenge ervan af, of plak je eigen exemplaar en controleer het aan de lengte- en tekensetregels van RFC 7636. Dezelfde SHA-256-base64url-afleiding die je autorisatieserver verwacht. Draait volledig in je browser.
Ping IdentityOIDC-decoder
Plak een OpenID Connect ID-token of een .well-known/openid-configuration-document en decodeer het: de kern-claims, profiel-claims, endpoints en mogelijkheden, met controles op vereiste claims, ondertekeningsalgoritme, nonce en PKCE.
Ping IdentitySAML 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 Identity
Artikelen
Anatomie van een JSON Web Token
De drie segmenten van een JWT, hoe de handtekening hem betrouwbaar maakt, en waarom een token decoderen niet hetzelfde is als hem verifiëren.
LezenJWKS 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.
LezenOpenID 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.
LezenJWK 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.
LezenJWT-ondertekenalgoritmen: HMAC, RSA en ECDSA
Waarom de alg-header van een JWT ertoe doet, het verschil tussen symmetrisch en asymmetrisch ondertekenen, en hoe te kiezen.
LezenThe 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.
LezenJWT-beveiligingsvalkuilen: alg:none, sleutelverwarring en ontbrekende controles
De handvol fouten die een JWT-verificateur in een vervalsingsmachine veranderen, en de validatie die een correcte verificateur moet uitvoeren.
LezenOIDC 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.
LezenVerifying 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.
LezenJWK 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.
LezenOIDC 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.
LezenToegangstokens, verniewingstokens en ID-tokens
Drie OAuth- en OpenID Connect-tokens die voortdurend verward worden, waar elk eigenlijk voor is, en waarom de verkeerde naar de verkeerde plek sturen een echte bug is.
LezenJWT 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.
LezenPublieke vs vertrouwelijke clients, en waar PKCE past
Of een OAuth-client een geheim kan bewaren beslist zijn hele beveiligingsmodel. Waarom SPA's en mobiele apps publieke clients zijn, en waarom PKCE nu voor ze allemaal wordt aanbevolen.
LezenThe 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.
LezenDe OAuth 2.0-autorisatiecodeflow
De vier rollen, de redirect-en-ruil-dans, en waarom de code op het achterkanaal wordt geruild voor een token.
LezenPKCE: de OAuth-autorisatiecodeflow beveiligen
De onderscheppingsaanval die PKCE verslaat, hoe de verifier en challenge in elkaar passen, en waarom S256 verplicht is.
LezenOpenID Connect: identiteit bovenop OAuth 2.0
Hoe OIDC authenticatie toevoegt aan de autorisatie van OAuth, wat het ID-token is en waarom de codestroom met PKCE het aanbevolen pad is.
LezenHow 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.
LezenValidating 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.
LezenProvisioning 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.
LezenInstalling 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.
LezenUpgrading 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.
LezenThe 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.
LezenWho 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.
LezenPingFederate 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.
LezenThe 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.
LezenPingFederate 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.
LezenHow 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.
LezenThe 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.
LezenPingFederate 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.
LezenLDAP 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.
LezenKerberos 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.
LezenSCIM: 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.
LezenThe 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.
LezenThe 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.
LezenPingOne: 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.
LezenPingOne 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.
LezenFrom 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.
Lezen