Kategori
Identiti & token
Semua alat dan artikel dalam kategori ini, dikumpulkan di satu tempat.
Alat
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 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.
Pengesah dan Challenge OAuth PKCE
Jana code_verifier OAuth 2.0 dan terbitkan code_challenge S256-nya, atau tampal milik anda sendiri dan semak ia mengikut peraturan panjang dan set aksara RFC 7636. Terbitan SHA-256 base64url yang sama seperti yang dijangka oleh pelayan kebenaran anda. Berjalan sepenuhnya dalam pelayar anda.
Ping IdentityPenyahkod dan Pengesah JWT
Nyahkod pengepala dan claim sesuatu JSON Web Token, baca tamat tempohnya dan pemasaannya dalam bahasa yang jelas, dan sahkan tandatangan HS256/384/512 dengan rahsia yang ditampal. Berjalan sepenuhnya dalam pelayar anda.
Ping IdentityPenyahkod OIDC
Tampal token identiti OpenID Connect atau dokumen .well-known/openid-configuration dan nyahkodkannya: claim teras, claim profil, endpoint dan keupayaan, dengan pemeriksaan untuk claim yang diperlukan, algoritma tandatangan, nonce dan 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
Artikel
Anatomi sesuatu JSON Web Token
Tiga segmen JWT, bagaimana tandatangan menjadikannya boleh dipercayai, dan mengapa menyahkod token bukan sama dengan mengesahkannya.
BacaJWKS 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.
BacaOpenID 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.
BacaAlgoritma tandatangan JWT: HMAC, RSA, dan ECDSA
Mengapa pengepala alg sesuatu JWT penting, perbezaan antara tandatangan simetri dan asimetri, dan cara memilih.
BacaJWK 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.
BacaThe 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.
BacaOIDC 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.
BacaPerangkap keselamatan JWT: alg:none, kekeliruan kunci dan semakan yang tertinggal
Segelintir kesilapan yang menukar pengesah JWT menjadi mesin pemalsuan, dan pengesahan yang mesti dilakukan pengesah yang betul.
BacaVerifying 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.
BacaJWK 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.
BacaOIDC 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.
BacaToken akses, token segar semula dan token ID
Tiga token OAuth dan OpenID Connect yang sentiasa dikelirukan, untuk apa sebenarnya setiap satu, dan mengapa menghantar yang salah ke tempat yang salah ialah pepijat sebenar.
BacaJWT 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.
BacaKlien awam vs sulit, dan di mana PKCE muat
Sama ada klien OAuth boleh menyimpan rahsia menentukan keseluruhan model keselamatannya. Mengapa SPA dan aplikasi mudah alih ialah klien awam, dan mengapa PKCE kini disyorkan untuk kesemuanya.
BacaThe 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.
BacaAliran kod kebenaran OAuth 2.0
Empat peranan, tarian ubah hala-dan-tukar, dan mengapa kod ditukar untuk token pada saluran belakang.
BacaPKCE: menjamin aliran kod kebenaran OAuth
Serangan pemintasan yang dikalahkan PKCE, bagaimana verifier dan challenge bercantum, dan mengapa S256 wajib.
BacaOpenID Connect: identiti di atas OAuth 2.0
Cara OIDC menambah pengesahan pada kebenaran OAuth, apa itu token ID, dan mengapa aliran kod dengan PKCE ialah laluan yang disyorkan.
BacaHow 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.
BacaValidating 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.
BacaProvisioning 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.
BacaInstalling 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.
BacaUpgrading 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.
BacaThe 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.
BacaWho 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.
BacaPingFederate 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.
BacaThe 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.
BacaPingFederate 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.
BacaHow 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.
BacaThe 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.
BacaPingFederate 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.
BacaLDAP 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.
BacaKerberos 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.
BacaSCIM: 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.
BacaThe 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.
BacaThe 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.
BacaPingOne: 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.
BacaPingOne 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.
BacaFrom 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.
Baca