Kategori
Kimlik ve token'lar
Bu kategorideki tüm araçlar ve makaleler, tek bir yerde toplandı.
Araçlar
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 Çözücü ve Doğrulayıcı
Bir JSON Web Token'ın başlığını ve claim'lerini çöz, son kullanma ve zamanlamasını sade bir dille oku ve yapıştırılan bir sırla bir HS256/384/512 imzasını doğrula. Tamamen tarayıcında çalışır.
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 Doğrulayıcı ve Challenge
Bir OAuth 2.0 code_verifier üret ve onun S256 code_challenge'ını türet veya kendininkini yapıştır ve RFC 7636'nın uzunluk ve karakter kümesi kurallarına göre denetle. Yetkilendirme sunucunun beklediği SHA-256 base64url türetmesinin aynısı. Tamamen tarayıcında çalışır.
Ping IdentityOIDC Çözücü
Bir OpenID Connect ID token'ı veya bir .well-known/openid-configuration belgesi yapıştırıp çözün: temel claim'ler, profil claim'leri, endpoint'ler ve yetenekler; gerekli claim'ler, imza algoritması, nonce ve PKCE denetimleriyle.
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
Makaleler
Bir JSON Web Token'ın anatomisi
Bir JWT'nin üç bölümü, imzanın onu nasıl güvenilir kıldığı ve bir token'ı kod çözmenin onu doğrulamakla aynı şey olmadığı.
OkuJWKS 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.
OkuOpenID 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.
OkuJWK 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.
OkuJWT imzalama algoritmaları: HMAC, RSA ve ECDSA
Bir JWT'nin alg başlığının neden önemli olduğu, simetrik ve asimetrik imzalama arasındaki fark ve nasıl seçileceği.
OkuThe 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.
OkuJWT güvenlik tuzakları: alg:none, anahtar karışıklığı ve eksik kontroller
Bir JWT doğrulayıcısını bir sahtecilik makinesine dönüştüren bir avuç hata ve doğru bir doğrulayıcının yapması gereken doğrulama.
OkuOIDC 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.
OkuVerifying 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.
OkuErişim token'ları, yenileme token'ları ve kimlik token'ları
Sürekli karıştırılan üç OAuth ve OpenID Connect token'ı, her birinin aslında ne işe yaradığı ve yanlış olanı yanlış yere göndermenin neden gerçek bir hata olduğu.
OkuJWK 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.
OkuOIDC 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.
OkuAçık ile gizli istemciler ve PKCE'nin yeri
Bir OAuth istemcisinin bir sır tutup tutamaması tüm güvenlik modeline karar verir. Neden SPA'lar ve mobil uygulamalar açık istemcilerdir ve neden PKCE artık hepsi için önerilir.
OkuJWT 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.
OkuThe 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.
OkuOAuth 2.0 yetkilendirme kodu akışı
Dört rol, yönlendir-ve-takas dansı ve kodun neden arka kanalda bir token'la takas edildiği.
OkuPKCE: OAuth yetkilendirme kodu akışını güvenceye almak
PKCE'nin yendiği ele geçirme saldırısı, verifier ile challenge'ın nasıl bir araya geldiği ve S256'nın neden zorunlu olduğu.
OkuOpenID Connect: OAuth 2.0 üzerinde kimlik
OIDC'nin OAuth'un yetkilendirmesine kimlik doğrulamayı nasıl eklediği, kimlik belirtecinin ne olduğu ve PKCE ile kod akışının neden önerilen yol olduğu.
OkuHow 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.
OkuValidating 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.
OkuProvisioning 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.
OkuInstalling 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.
OkuUpgrading 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.
OkuThe 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.
OkuWho 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.
OkuPingFederate 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.
OkuThe 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.
OkuPingFederate 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.
OkuHow 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.
OkuThe 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.
OkuPingFederate 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.
OkuLDAP 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.
OkuKerberos 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.
OkuSCIM: 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.
OkuThe 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.
OkuThe 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.
OkuPingOne: 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.
OkuPingOne 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.
OkuFrom 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.
Oku