OAuth

Cybersecurity / 20 Sep 2026 / 6 min read

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary

JWT Audience Checks Keep Tokens Inside Their Intended Service Boundary A valid JSON Web Token signature proves a narrow fact: the token bytes were signed with a key accepted by the verifier and were not modified afterward without invalidating that signature. That result does not establish that the token was issued for the service currently receiving it. This distinction matters in systems where one authority issues tokens for several APIs, or where multiple authorities use keys that an application can reach through configuration. A token can be cryptographically valid yet belong to a different security context. The iss and aud claims give the verifier inputs for enforcing that boundary.

Cybersecurity JWT

Cybersecurity / 20 Sep 2026 / 7 min read

DPoP Binds OAuth Access Tokens to a Client Key

DPoP Binds OAuth Access Tokens to a Client Key A bearer access token is usable by any party that obtains the token and can present it to the resource server. TLS protects the token while it crosses a correctly authenticated connection, but it does not change that bearer property after the token reaches an endpoint, log, process, browser context, or other storage location. Demonstrating Proof of Possession (DPoP), specified by RFC 9449, adds a key-bound layer at the application protocol. The client creates an asymmetric key pair and signs a DPoP proof JWT. An authorization server can bind an issued access token to the public key represented by that proof. The resource server then requires both the token and a valid proof created with the corresponding private key.

Cybersecurity OAuth

Cybersecurity / 19 Sep 2026 / 7 min read

OAuth mTLS Certificate Binding Moves Token Proof into the TLS Connection

OAuth mTLS Certificate Binding Moves Token Proof into the TLS Connection An OAuth access token can pass every syntactic and cryptographic check at a resource server and still be insufficient for access. With a mutual-TLS certificate-bound token, the server also needs evidence from the TLS connection: the client presenting the token must possess the private key corresponding to the certificate associated with that token. That changes the security boundary. A bearer token is usable by a party that obtains the token value, subject to the token’s other restrictions. A certificate-bound token adds a separate possession requirement tied to the TLS client certificate. The token and the private key become two pieces of the same authorization path.

Cybersecurity OAuth

Cybersecurity / 19 Sep 2026 / 6 min read

DPoP Binds OAuth Tokens to Client Keys, Not to Client Identity

A bearer access token normally authorizes whichever party can present its value to a resource server. Copying the token can therefore move its authority away from the client that originally received it. OAuth 2.0 Demonstrating Proof of Possession, or DPoP, changes that property by binding a token to a public key and requiring a signed proof from the corresponding private key during presentation. That binding narrows one important failure mode, but it does not turn the key into a universal client identity. DPoP is an application-layer sender-constraining mechanism. Its guarantees depend on the token binding, proof validation, replay policy, TLS, and the security of the client execution context.

Cybersecurity OAuth

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 / 14 Sep 2026 / 7 min read

PKCE Binds an OAuth Code to the Client That Started the Flow

An OAuth authorization code can pass through a browser, an operating-system URL dispatcher, a custom application scheme, or an application link before it reaches the client that requested it. That route is convenient, but it also means possession of the returned code is not always strong evidence that the intended client received it. Proof Key for Code Exchange, usually called PKCE, changes the value of an intercepted code. Before starting the authorization request, the client creates a high-entropy secret called the code verifier. The authorization server receives a derived code challenge with the request and later requires the original verifier when the code is exchanged for tokens. A party that captures only the authorization code lacks the second value needed to complete the exchange.

Cybersecurity OAuth

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 / 10 Sep 2026 / 12 min read

Bind OAuth Callbacks to the Login That Started Them

An OAuth callback can look valid even when it belongs to the wrong browser interaction. The authorization server may have issued a real code, the redirect URI may be correct, and the code exchange may succeed. Yet if the client cannot tell whether this browser actually started that authorization flow, it can attach the wrong external identity or authorization to the current session. This is a form of cross-site request forgery at the OAuth callback. In a login flow, one possible consequence is login CSRF: a victim can end up signed into the client as an account associated with someone else. The details vary by application, but the defensive question stays the same: does this callback belong to a login transaction that this user agent started?

Cybersecurity OAuth

Cybersecurity / 07 Sep 2026 / 9 min read

Match OAuth Redirect URIs Exactly

An OAuth authorization server eventually has to answer a deceptively simple question: where may it send the browser after authorization? If that destination is validated too loosely, an authorization response intended for one client can be sent somewhere the client does not control. In an authorization-code flow, that can expose the authorization code to another endpoint. Other protections may still limit what can be done with a leaked code, but redirect validation should not create the leak in the first place.

Cybersecurity OAuth