Identity Security

Cybersecurity / 16 Sep 2026 / 8 min read

PKCE Binds OAuth Authorization Codes to a Per-Request Verifier

A native application starts an OAuth authorization flow in the system browser, then waits for the operating system to route the redirect back to the app. The authorization endpoint is protected by TLS, yet the returned authorization code crosses a different boundary: application dispatch on the local device. Another application able to receive that redirect may obtain the code before the intended client does. Proof Key for Code Exchange, or PKCE, changes the value of that intercepted code. The client creates a transaction-specific secret called the code_verifier, sends only a derived code_challenge in the authorization request, and later presents the verifier when redeeming the code. The authorization server binds the challenge to the issued code. Possession of the code alone is then insufficient for redemption.

Cybersecurity OAuth

Cybersecurity / 13 Sep 2026 / 8 min read

Password Reset Is an Authentication Ceremony

A password reset endpoint can be quieter than the login page and still hold more authority. A successful login proves possession of an existing credential. A successful reset replaces that credential, often after a single email link has crossed several systems outside the application’s direct control. That makes account recovery an authentication ceremony in its own right. Treating it as a support feature creates a dangerous asymmetry: the primary login path receives rate limits, multifactor checks, session controls, and detailed telemetry, while the recovery path is reduced to “email a token and accept a new password.”

Cybersecurity Authentication

Cybersecurity / 13 Sep 2026 / 8 min read

Client Certificates Need an Identity Lifecycle

Client Certificates Need an Identity Lifecycle A service can reject every connection that lacks a trusted client certificate and still have a weak machine-identity boundary. The cryptographic handshake may be sound while the surrounding identity system quietly grants stale, ambiguous, or overly broad authority. Mutual TLS, commonly shortened to mTLS, gives both sides of a TLS connection a chance to authenticate with certificates. On the server side, this resembles familiar HTTPS authentication. On the client side, the server requests a certificate and verifies the presented chain and proof of private-key possession. That is a strong primitive. It does not, by itself, decide what the authenticated workload is allowed to be.

Cybersecurity Identity Security

Cybersecurity / 12 Sep 2026 / 8 min read

Passkey Recovery Can Reopen the Password Era

Passkey Recovery Can Reopen the Password Era A service can deploy passkeys, remove passwords from its normal sign-in screen, and still retain a password-grade account takeover path. The weak point often sits outside the authentication ceremony itself: recovery. Passkeys change the primary credential model in useful ways. WebAuthn credentials are scoped to a relying party, and authentication uses public-key cryptography rather than a reusable secret sent to the server. The browser and authenticator also participate in origin and relying-party checks, which gives passkeys strong resistance to conventional credential phishing.

Cybersecurity Passkeys

Cybersecurity / 12 Sep 2026 / 7 min read

OAuth Redirect Security Depends on Transaction Binding

OAuth Redirect Security Depends on Transaction Binding An OAuth callback can arrive over HTTPS, carry a valid authorization code, and still belong to the wrong transaction. That is the uncomfortable property of redirect-based authorization: transport protection can establish who served each endpoint, but it does not by itself prove that a response belongs to the browser session, client instance, authorization server, and callback context that initiated the exchange. The modern authorization code flow addresses this with several bindings rather than a single defensive parameter. Exact redirect URI matching constrains the destination. PKCE binds an authorization code to a verifier held by the client. CSRF protections bind the browser-facing response to the initiating transaction. Issuer identification matters when one client talks to more than one authorization server.

Cybersecurity OAuth

Cybersecurity / 12 Sep 2026 / 6 min read

JWT Verification Is a Policy Decision Before It Is a Crypto Check

JWT Verification Is a Policy Decision Before It Is a Crypto Check A JWT can carry a valid signature and still be unacceptable to the service receiving it. The signature proves only that the token matches a cryptographic key under a particular algorithm. It does not establish that the key belongs to an issuer the service trusts, that the algorithm is permitted for this token class, or that the claims authorize use at this endpoint.

Cybersecurity JWT

Cybersecurity / 07 Sep 2026 / 10 min read

Do Not Use Personal Questions for Account Recovery

A login flow can use strong passwords and multi-factor authentication, yet the account can still be easier to take over through its recovery path. If a user who cannot sign in only needs to answer questions such as a birth city, school name, or family detail, the recovery process may accept evidence that another person can discover, infer, or repeatedly guess. That makes personal security questions a poor substitute for authentication. The problem is not merely that some questions are badly chosen. The deeper problem is that facts about a person are usually not secrets designed for authentication: they can be shared, become public, remain unchanged for years, and be known by people other than the account owner.

Cybersecurity Authentication

Cybersecurity / 07 Sep 2026 / 9 min read

Bind Invitations to the Intended Recipient

An invitation link often looks like a simple onboarding convenience: an administrator enters an email address, the application sends a link, and the recipient joins a workspace or project. But accepting that invitation creates authorization. If the application checks only that the link contains a valid token, whoever presents the token may receive the membership. That distinction matters when invitation messages are forwarded, opened in a shared mailbox, exposed through another system, or clicked while the browser is signed in to a different account. A strong random token can prove that someone possesses the invitation link. By itself, it does not prove that the signed-in account is the person the inviter intended to authorize.

Cybersecurity Authorization

Cybersecurity / 07 Sep 2026 / 10 min read

Bind Access Grants to Stable Principal Identifiers

An application may grant access to alex@example.test and appear to work correctly for years. Then Alex changes address, leaves the organization, or the old address is assigned to someone else. If the authorization system treats that address as the identity itself, access can follow the label instead of the person or service that was originally approved. This is an identity-binding problem. Authorization needs to answer not only what may this requester do? but also which principal does this grant actually belong to? A principal is the security identity that receives permissions, such as a user account or service account.

Cybersecurity Authorization

Cybersecurity / 06 Sep 2026 / 11 min read

Review Access Before Privileges Become Permanent

Access control can be correct on the day a permission is granted and still become risky later. A developer changes teams but keeps access to an old production project. A contractor finishes an engagement while a group membership remains active. A service account stops using a privileged operation, but its role is never reduced. None of these cases requires a broken authorization check. The system may enforce every permission exactly as configured. The problem is that the configured access no longer matches the current need.

Cybersecurity Access Control