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.
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.
BacaRADIUS end to end: one 802.1X login, packet by packet
What a switch and a RADIUS server actually say to each other when a laptop plugs in: the packet fields and codes of RFC 2865, the attributes that carry the identity and the policy, the EAP conversation relayed in EAP-Message attributes, the VLAN assignment of RFC 3580, the Start and Stop records of RFC 2866, the server-initiated Change of Authorization of RFC 5176, the proxy chain, and the two things the shared secret does and does not protect. Every number from the RFC it comes from.
BacaTACACS+ for device administration: a login and a command, exchange by exchange
How a router asks a server whether an engineer may log in, whether the command just typed may run, and how it records that it ran: the three packet types of RFC 8907, the 12-byte header, the START, REPLY and CONTINUE of authentication, the per-command authorization with its name=value arguments, the START, STOP and WATCHDOG of accounting, the obfuscation the RFC refuses to call encryption, the 1993 ancestor of RFC 1492, and the method-list discipline that keeps an estate reachable when the servers are not.
Baca802.1X and the EAP methods: the port, the envelope, and the choice that carries the security
Port-based network access control from the frame up: the supplicant, authenticator and server, EAPOL and the controlled port, the four EAP codes of RFC 3748, and then the decision that actually matters, which method runs inside the envelope. EAP-TLS, PEAP, EAP-TTLS, EAP-FAST, TEAP, EAP-pwd, EAP-SIM and EAP-AKA compared on what each authenticates with, what it protects, and what it needs on the client, with the one setting that undoes most of them, the VLAN assignment the server returns, and the fallbacks for devices that cannot do any of it.
BacaNTLM explained: three messages, three versions, and why it is still on your network
What NT LAN Manager actually is, from Microsoft's own specification: a challenge-response carried inside other protocols, in NEGOTIATE, CHALLENGE and AUTHENTICATE messages that begin with the signature NTLMSSP; the connection-oriented and connectionless variants; the LM, NTLMv1 and NTLMv2 versions that share one flow and differ in the response function; how to recognise it in an HTTP header; why it survives wherever Kerberos cannot reach; what pass-the-hash and relay mean for it; and how to find what still depends on it before turning it off.
BacaWeb authentication and captive portals: the third door onto an authenticated port
How a switch or controller logs in a person whose device cannot do 802.1X: the web authentication proxy of Cisco's switch guide, the intercepted HTTP session and the login page, the policy downloaded on success, the fail and expired pages and the watch list, host detection by ARP and DHCP snooping, local against central web authentication, the HTTPS limit that is breaking interception everywhere, and the IETF's replacement for the trick, the captive portal architecture of RFC 8952 and the DHCP and router advertisement options of RFC 8910 that tell a device a portal exists instead of forging answers.
Baca