Authentication · XB Field Notes

OAuth code flow trades a code for a token

Wed, 20 Oct 2027 00:00:00 +0000

Authorization-code flow moves access-token delivery to the token endpoint rather than returning an access token in the browser-facing authorization redirect. That distinction reduces exposure in URLs, but does not mean a browser can never hold a token. The client architecture determines who exchanges the code and where the resulting credentials live.

The authorization redirect carries a code; the token endpoint delivers tokens. PKCE, client and callback binding, expiry, and single use protect different boundaries. Storage follows the client architecture, and the offline model does not validate a complete login.

Public clients can use code flow

A confidential web backend can authenticate to the token endpoint and retain tokens server-side. A browser then uses an application session whose security still needs attention. Public clients, including native applications and browser applications, cannot reliably keep a distributed client secret confidential. They can nevertheless use authorization-code flow with PKCE; it is not reserved for backends.

For a browser application performing its own exchange, JavaScript receives the token response. Code flow avoids access-token delivery in the authorization URL, but does not remove script compromise or token-storage risks. A backend-based design changes those boundaries rather than eliminating all browser-side risk. OAuth delegates access; an application needing user authentication should use an appropriate identity protocol such as OpenID Connect and validate its separate artifacts.

Bind the exchange to the original request

PKCE begins with a high-entropy verifier generated for the transaction. The authorization request carries its S256 challenge; the token request supplies the verifier. The authorization server checks that they correspond. The verifier is not a static client password and must remain associated with the initiating transaction. An intercepted code alone should not be sufficient to redeem it.

RFC 9700 requires PKCE for public clients and recommends it for confidential clients. Use S256 rather than a downgrade to plain. Confidential clients still perform their configured client authentication; PKCE does not replace that responsibility. Client authentication also need not mean transmitting a shared client secret: deployments can use asymmetric mechanisms.

Bind each code to its client and redirect URI, keep its lifetime short, and enforce single use. Compare registered redirect URIs exactly, with the standardized native-loopback port exception where applicable. When redirect_uri appeared in the authorization request, its token-request value must match. Reject unknown callbacks at authorization time rather than waiting until a stolen code reaches the token endpoint.

When it breaks

Single use does not prevent an attacker from redeeming an unprotected code first. Expiry bounds the opportunity without making interception harmless. Logs, browser history, referrers, and crash reports can still expose callback codes. Avoid recording them, use appropriate HTTPS redirect endpoints, and apply the specific native-loopback rules when building native clients.

Clients must prevent callback CSRF and code injection. Securely bind transaction state to the initiating browser session, and use the relevant state, PKCE, or OpenID Connect protections according to the protocol and provider guarantees. A random state value checked without session binding is not enough. Multiple authorization servers also require protection against issuer mix-up; a successful exchange alone does not establish the expected identity provider.

Refresh-token protection is a separate lifecycle. For public clients, the security best practice requires sender-constrained refresh tokens or rotation. Rotation with reuse detection is one solution, not a universal claim that every unchanged refresh token is infinitely valid. Expiry, revocation, inactivity limits, and client binding determine the actual exposure window.

Check it quickly

Save as oauth_code_demo.py and run python3 oauth_code_demo.py. This offline, single-threaded model uses synthetic client identifiers, an explicitly registered callback, fresh random codes, and an injected clock. The helper receives the verifier to compute the challenge locally; a real authorization request sends only the challenge, never the verifier.

import base64
import hashlib
import hmac
import re
import secrets

REGISTERED = {'demo-client': 'https://app.example.test/callback'}
CODES = {}
NOW = 1_800_000_000


def challenge(verifier):
 if not re.fullmatch(r'[A-Za-z0-9._~-]{43,128}', verifier):
 raise ValueError('invalid verifier syntax')
 return base64.urlsafe_b64encode(hashlib.sha256(verifier.encode('ascii')).digest()).rstrip(b'=').decode()


def authorize(client, redirect, verifier, now):
 if REGISTERED.get(client) != redirect:
 raise ValueError('unregistered redirect')
 code = secrets.token_urlsafe(32)
 CODES[code] = {'client': client, 'redirect': redirect, 'challenge': challenge(verifier),
 'expires': now + 60, 'used': False}
 return code


def exchange(code, client, redirect, verifier, now):
 entry = CODES.get(code)
 if entry is None:
 raise ValueError('unknown code')
 if entry['used']:
 raise ValueError('code already used')
 if now >= entry['expires']:
 raise ValueError('code expired')
 if client != entry['client'] or redirect != entry['redirect']:
 raise ValueError('client or redirect mismatch')
 if not hmac.compare_digest(challenge(verifier), entry['challenge']):
 raise ValueError('PKCE verifier mismatch')
 # Atomic only because this demonstration runs sequentially in one thread.
 entry['used'] = True
 return 'DEMO-' + secrets.token_urlsafe(32)


def rejected(label, operation):
 try:
 operation()
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


client = 'demo-client'
redirect = REGISTERED[client]
verifier = secrets.token_urlsafe(32)
code = authorize(client, redirect, verifier, NOW)
rejected('wrong client', lambda: exchange(code, 'other-client', redirect, verifier, NOW))
rejected('wrong redirect', lambda: exchange(code, client, redirect + '/extra', verifier, NOW))
rejected('wrong verifier', lambda: exchange(code, client, redirect, 'x' * 43, NOW))
if not exchange(code, client, redirect, verifier, NOW).startswith('DEMO-'):
 raise RuntimeError('valid exchange failed')
rejected('replay', lambda: exchange(code, client, redirect, verifier, NOW))
stale = authorize(client, redirect, verifier, NOW)
rejected('exact expiry', lambda: exchange(stale, client, redirect, verifier, NOW + 60))
rejected('unregistered callback', lambda: authorize(client, 'https://other.example.test/', verifier, NOW))
print('PASS: bound code accepted once; six negative cases rejected')

Expect six rejection lines and PASS. A correct exchange succeeds once. Wrong client, altered redirect, and incorrect verifier fail before consuming that code; replay fails afterward. A second code fails exactly at its expiry, and an unregistered callback is rejected before issuance. No code or token is printed or transmitted, and no real identity provider is involved.

The model is deliberately narrower than a deployed authorization server. Its sequential check-and-mark operation does not test concurrency: production storage must consume codes atomically. It omits HTTP processing, consent, client authentication, browser-session binding, issuer validation, and refresh-token handling. Use these cases as requirements for integration tests against an isolated provider configuration; passing the in-memory exercise does not demonstrate the full login journey.

Sources

RFC 6749: OAuth 2.0, authorization code binding and token exchange, checked 2026-10-15.
RFC 7636: PKCE, verifier syntax and S256 challenges, checked 2026-10-15.
RFC 9700: OAuth 2.0 Security Best Current Practice, public clients, redirects, CSRF, and refresh-token protections, checked 2026-10-15.
RFC 8252: OAuth 2.0 for Native Apps, public native clients and loopback redirects, checked 2026-10-15.

Cookies and sessions hold boundaries

Tue, 12 Jan 2027 00:00:00 +0000

A cookie is a browser storage and transport mechanism. A server-side session is one application design that uses a cookie value to locate stored state. Keeping those responsibilities separate makes login, expiry, and logout testable. This article follows an opaque session identifier, rather than repeating the host, path, or SameSite matching rules.

Cookie lifetime governs browser storage; session validity and action authorization belong to the server. Replace and invalidate old identifiers, then test replay. The two timer examples use article-fixture units and do not establish browser or distributed-system behavior.

A bearer identifier still carries authority

In this design, the server generates an unpredictable identifier and associates it with a session record. The value is opaque to the client, but possession can still authorize access: anyone who steals a valid bearer identifier may replay it. Calling it “only a pointer” must not suggest that it is harmless. Avoid putting it in URLs, logs, or diagnostic screenshots.

Plain client-controlled roles must not be trusted. However, meaningful data in a cookie is not automatically forgeable: correctly authenticated, signed session formats are another design. Signing protects integrity, not confidentiality, and stateless designs still need explicit expiry, key management, and revocation decisions. Choose a maintained session framework instead of inventing a format merely to avoid a server lookup.

For an opaque scheme, generate tokens with a cryptographically secure random generator and adequate entropy. Reject unknown identifiers rather than creating privileged state under an arbitrary client-supplied value. Resolve the session on the server and authorize each operation against current permissions. An authenticated session does not automatically grant access to every object or every administrative action.

Two lifetimes need two controls

Cookie Max-Age and Expires govern client storage; they do not expire the server’s session record. A non-browser client can retain and replay the value after the browser would delete it. Likewise, a browser-session cookie can survive through session-restore behavior. Enforce absolute and idle expiry on the server, with explicit boundary comparisons and a consistent time source.

Logout must invalidate server-side state as well as clear the browser cookie at the matching scope. Otherwise a copied token remains useful. Rotating the identifier after authentication and privilege changes helps prevent fixation, but only if the previous identifier loses its authority. Concurrent requests and distributed stores require careful coordination so an old request cannot silently recreate a revoked session.

Secure and HttpOnly protect transport and script access respectively; HttpOnly does not prevent injected script from making authenticated requests. SameSite is a browser-context defense, not server expiry or permission checking. Cookie and header limits also vary across browsers and servers: there is no universal eight-kilobyte request-header limit. Keeping the token compact avoids unnecessary overhead without pretending size alone determines security.

When it breaks

A login upgrades a pre-authentication record while keeping an identifier that an attacker already knows. A logout deletes only the cookie, leaving a copied value valid. An idle timeout is checked only by JavaScript, allowing a direct client to continue. These failures all occur on the server lifecycle even if every cookie attribute looks correct in developer tools.

Do not assume periodic activity should extend access forever. An idle timer can slide with accepted activity while an absolute deadline remains fixed for that session. Decide whether reauthentication or privilege elevation begins a new lifetime. State the policy explicitly so a token refresh does not accidentally reset an intended hard limit indefinitely.

Check it quickly

Save this as session-lifecycle.py and run python3 session-lifecycle.py with Python 3.11 or newer. It uses synthetic users, predictable fixture identifiers, and an injected clock. It opens no sockets and provides no authentication service. Never use the identifier generator or this in-memory model for a real application.

from itertools import count

# Predictable identifiers are deliberate fixtures, never production tokens.
identifiers = count(1)
sessions = {}
IDLE = 30
ABSOLUTE = 100


def issue(user, role, now):
 sid = f"fixture-{next(identifiers)}"
 sessions[sid] = {"user": user, "role": role, "born": now, "last": now}
 return sid


def lookup(sid, now):
 session = sessions.get(sid)
 if session is None:
 return None
 if now - session["born"] >= ABSOLUTE or now - session["last"] >= IDLE:
 sessions.pop(sid)
 return None
 session["last"] = now
 return session.copy()


def rotate(sid, user, role, now):
 assert lookup(sid, now) is not None
 sessions.pop(sid)
 return issue(user, role, now)


def logout(sid):
 sessions.pop(sid, None)


assert lookup("attacker-chosen", 0) is None
anonymous = issue(None, "anonymous", 0)
authenticated = rotate(anonymous, "demo-user", "reader", 1)
assert authenticated != anonymous and lookup(anonymous, 1) is None
privileged = rotate(authenticated, "demo-user", "editor", 2)
assert lookup(authenticated, 2) is None
assert lookup(privileged, 2)["role"] == "editor"
logout(privileged)
assert lookup(privileged, 3) is None
print("PASS: unknown ID, login rotation, privilege rotation, and logout")

idle = issue("demo-user", "reader", 0)
assert lookup(idle, 20) is not None
assert lookup(idle, 50) is None
active = issue("demo-user", "reader", 0)
for now in (20, 40, 60, 80, 99):
 assert lookup(active, now) is not None
assert lookup(active, 100) is None
assert not sessions
print("PASS: idle and absolute expiry reject at the configured boundary")

The first line confirms rejection of an unknown identifier, replacement after login and elevation, rejection of the replaced identifiers, and logout invalidation. Rotation deliberately begins a new fixture lifetime; the policy is visible in issue. The second line checks expiry exactly at thirty idle units and one hundred absolute units, even with activity just before the absolute deadline.

The assertions test lifecycle logic, not entropy, browser behavior, persistent storage, concurrent rotation, or distributed revocation. Production verification should replay an old synthetic session after login, elevation, logout, and timeout through the actual application. Verify both rejection and the absence of side effects. A successful cookie-deletion response alone does not establish that the old credential stopped working.

Sources

OWASP Session Management, unpredictable identifiers, regeneration, expiry and invalidation, checked 2026-10-15.
RFC 6265: cookie lifetime, cookie storage lifetime and attributes, checked 2026-10-15.
RFC 7519: JWT, signed-token security considerations and trust decisions, checked 2026-10-15.

SSO delegates authentication; the app still verifies

Tue, 17 Nov 2026 00:00:00 +0000

Single sign-on lets an application rely on an identity provider’s authentication result. The user does not need to hand that provider password to each application. The application still owns its authorization decisions, local sessions, and integration configuration; confidential clients may also hold client credentials. Delegating authentication does not remove the application’s security boundary or guarantee that every future login can skip user interaction.

SSO relays an authentication result into the application’s own security boundary. The app still verifies the token, binds the request, and controls sessions and access. Decoding establishes no identity; ID Token expiry does not automatically end an application session.

Identify the protocol and the token

SAML and OpenID Connect support federation through different protocols, not merely interchangeable XML and JSON encodings. This article focuses on OIDC: an identity layer over OAuth 2.0 that returns an ID Token about authentication. An access token authorizes access to a resource and may use a different format. A JWT-shaped string is not automatically an ID Token, and a resource server should not accept one just because it came from a familiar provider.

For an OIDC ID Token, validate the expected issuer, intended client audience, expiration, and any requested nonce using the selected flow’s rules. Apply the relevant authorized-party and authentication-context checks too. A correctly signed token for another client is still unsuitable. Match the signing keys to the trusted issuer; an attacker-controlled issuer string must not select an arbitrary metadata server.

Configure the verifier’s allowed algorithms and key types independently of untrusted input. The header’s algorithm must agree with that policy and the operation actually performed. HS256 is not inherently invalid: OIDC defines negotiated MAC-based signing with an appropriate shared secret. Treating an RSA public key as that secret is algorithm confusion. An unfamiliar key identifier may be legitimate rotation, but must never justify skipping verification.

When it breaks

Decoding is the most misleading success. Base64url and JSON parsing can reveal plausible claims without establishing who issued them. An administrative subject, matching audience, and future expiration can all be invented. Do not paste live tokens into online decoders or incident logs; they can expose personal claims and usable credentials. Inspect only selected fields through an approved diagnostic path.

Login-flow binding matters alongside token validation. Use a maintained OIDC integration with the redirect, request-correlation, and PKCE protections appropriate to its client and flow. RFC 9700 gives current OAuth security guidance. A checklist of four JWT fields cannot replace that integration, and accepting a token from the wrong request can remain dangerous even when its signature is genuine.

Check it quickly

Save this as inspect-sso-fixture.py and run python3 inspect-sso-fixture.py with assertions enabled. It uses only fabricated values, no provider, keys, credentials, network, or third-party packages. This is a complete demonstration of decoding’s limits, not a production token parser or authentication implementation:

import base64
import json


def encode(value):
 raw = json.dumps(value, separators=(",", ":")).encode()
 return base64.urlsafe_b64encode(raw).rstrip(b"=").decode()


def inspect_fixture(token):
 header, payload, signature = token.split(".")
 decode = lambda part: json.loads(base64.urlsafe_b64decode(
 part + "=" * (-len(part) % 4)))
 return {"header": decode(header), "claims": decode(payload),
 "signature_text": signature, "verified": False}


header = {"alg": "RS256", "kid": "invented-key"}
claims = {"iss": "https://issuer.example", "aud": "billing",
 "sub": "user-7", "exp": 2000000000}
first = encode(header) + "." + encode(claims) + ".not-a-signature"
second = encode(header) + "." + encode(dict(claims, sub="admin")) + ".not-a-signature"
rows = [inspect_fixture(token) for token in (first, second)]
assert [row["claims"]["sub"] for row in rows] == ["user-7", "admin"]
assert all(row["header"]["alg"] == "RS256" for row in rows)
assert all(row["verified"] is False for row in rows)
print("decoded subjects: user-7, admin")
print("cryptographic verification performed: False")

Both strings name RS256, billing, and the same issuer. Changing the subject to admin requires no signing key because the final component is invented text. The script prints both subjects and explicitly reports that no cryptographic verification occurred. It does not validate signatures, expiry, audience, or issuer discovery; the false verification field prevents the output from masquerading as an authentication result.

For a real integration, a separate test suite must reject a wrong issuer, wrong audience, expired token, failed signature, mismatched request nonce, and inappropriate token type. Exercise supported key rotation and error handling with the actual library and provider. Those integration cases are requirements to verify in that environment, not results established by this local fixture.

Give logout its own contract

The provider session, application session, access token, and refresh token have separate lifetimes. Expiration of the ID Token used during login does not automatically destroy an application cookie or server-side session. Short token lifetimes therefore do not, by themselves, define how quickly disabling an account removes existing application access.

JWT’s jti is an optional identifier, not a mandatory universal revocation-list lookup. If immediate logout is required, choose a supported mechanism and verify the application actually ends the identified sessions. OIDC back-channel logout defines a separately validated logout message and session-clearing action. Token introspection, where supported, answers a token-status question; it does not automatically invalidate an unrelated application session. Record the offboarding guarantee and its failure behavior explicitly.

Sources

OIDC Core, ID Token validation, identity tokens, issuer/audience/nonce checks, and negotiated algorithms, checked 2026-10-15.
RFC 8725, JWT best practices, algorithm policy, trusted issuers, and cross-token confusion, checked 2026-10-15.
RFC 7519, JWT ID, optional identifier and replay use, checked 2026-10-15.
RFC 9700, OAuth security, redirect-flow and PKCE protections, checked 2026-10-15.
OIDC back-channel logout, logout-token validation and application session termination, checked 2026-10-15.
SAML 2.0 Core, assertions and protocol messages, checked 2026-10-15.
RFC 7662, token introspection, token metadata and active status, checked 2026-10-15.

Keep reusable access tokens out of request URLs

Sun, 01 Nov 2026 00:00:00 +0000

A reusable bearer access token grants its holder defined access; sender-constrained tokens additionally require proof tied to the sender. Putting it in a URL exposes that capability to systems that routinely copy URLs: access logs, monitoring records, browser navigation history, bookmarks, and shared links. The exact exposure depends on the request and policy, but a secret-looking query parameter is not automatically protected by its name. Treat transport placement as part of the credential’s disclosure boundary.

For OAuth bearer-token requests, use the Authorization header. RFC 9700 now prohibits clients from passing access tokens in URI query parameters using RFC 6750’s query method. HTTPS remains essential: moving a value from the query to a header does not encrypt it, and TLS protects request data in transit to its termination point. After termination, applications and intermediaries can still inspect it. A header keeps the value out of the request URL, rather than granting immunity from logging or diagnostic capture.

Distinguish reduced exposure from secrecy

Some access logs record only method, request target, and status. In that format, a header token does not appear in the target, while a query token does. Other systems capture request headers, so Authorization needs explicit handling in log, trace, and error-reporting configuration. Verify what the actual pipeline stores instead of assuming that headers bypass every logging layer. Avoid exposing real credentials while performing that inspection.

Referrer-Policy can reduce onward source-URL disclosure, but does not remove a query already sent to the destination, erase browser records, or rewrite copied links. Likewise, Cache-Control: no-store is not a general instruction to purge access logs or navigation history. Moving a token to a fragment changes what is sent in an HTTP request, but still leaves a value accessible to page scripts and browser URL state; it is not a universal credential-storage solution.

When it breaks

A team may replace query authentication with a header and leave old token-bearing URLs in reports or shared bookmarks. The transport change does not undo that exposure. Investigate the affected copies and invalidate exposed reusable credentials where the system supports it. Another failure is a supposedly temporary link whose capability remains useful to anyone who obtains it during its validity period. Short lifetime reduces that window without making disclosure harmless.

Signed URLs can be an intentional design for narrowly scoped resource access when the chosen client flow requires them. Their allowed resource, operation, expiry, and handling need explicit review. Expiration is not the same as single use: preventing reuse before expiry requires a mechanism that actually enforces consumption. A webhook or browser navigation does not automatically justify putting an unrestricted reusable API credential into a query; choose an authentication flow suitable for the real client.

Header placement reduces URL exposure; headers still need protection. Signed-resource URLs are a separately scoped design, not an OAuth exception. Runtime and technical checks remain blocked.

Check it quickly

Save this as token-placement.py, run python3 token-placement.py --serve, and open its printed page. The original article reports Python 3.14.4 and Chrome 152; this source review did not reproduce that run. Explicit Python checks also run under optimization. Every value is the literal synthetic marker DEMO-NOT-A-SECRET; never substitute a real credential. The loopback server is an observation fixture, not an authentication service. It records request targets and whether a demonstration Authorization header was present, without recording that header’s value. Python disables proxy discovery and rejects redirects; control browser proxy policy separately. Serve mode lasts 120 seconds, with --serve-seconds limited to 1–300. Control-C also requests cleanup. Only the separate cleanup result confirms that the server thread stopped and listener closed; bounded joins fail if shutdown remains unverified.

import argparse
import json
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.parse import urlsplit
from urllib.request import HTTPRedirectHandler, ProxyHandler, Request, build_opener

parser = argparse.ArgumentParser()
parser.add_argument("--serve", action="store_true")
parser.add_argument("--serve-seconds", type=int, default=120)
args = parser.parse_args()
if not 1 <= args.serve_seconds <= 300:
 parser.error("--serve-seconds must be between 1 and 300")

def require(condition, message):
 if not condition:
 raise AssertionError(message)

# Synthetic demonstration value only; this server is not an authentication service.
demo = "DEMO-NOT-A-SECRET"
events = []


class NoRedirect(HTTPRedirectHandler):
 def redirect_request(self, req, fp, code, msg, headers, newurl):
 raise RuntimeError("Unexpected redirect in local fixture")


opener = build_opener(ProxyHandler({}), NoRedirect())


class LocalServer(HTTPServer):
 def get_request(self):
 connection, address = super().get_request()
 connection.settimeout(2)
 return connection, address


class Handler(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 path = urlsplit(self.path).path
 if path == "/events":
 body = json.dumps(events).encode()
 kind = "application/json"
 elif path == "/echo":
 entry = {"request_target": self.path,
 "authorization_present": self.headers.get("Authorization") == "Bearer " + demo,
 "referer": self.headers.get("Referer")}
 events.append(entry)
 body = json.dumps(entry).encode()
 kind = "application/json"
 elif path == "/":
 events.append({"request_target": self.path, "document": True})
 body = ("""<!doctype html><meta charset="utf-8"><title>Token placement lab</title>
<h1>A clean referrer does not erase the request URL</h1><pre id="result">Running...</pre><script>
const demo=""" + json.dumps(demo) + """;
function require(condition, message) {
 if (!condition) throw new Error(message);
}
function verifyObservation(result, origin) {
 const queryTarget='/echo?access_token='+demo;
 require(new URL(result.page).origin===origin &&
 new URL(result.page).pathname==='/' &&
 new URL(result.page).search==='?access_token='+demo, 'page URL mismatch');
 require(result.query.request_target===queryTarget &&
 result.query.authorization_present===false, 'query placement mismatch');
 require(result.header.request_target==='/echo' &&
 result.header.authorization_present===true, 'header placement mismatch');
 require(result.query.referer===null && result.header.referer===null,
 'Referer was not suppressed');
 require(result.resourceUrls.includes(origin+queryTarget) &&
 result.resourceUrls.includes(origin+'/echo'), 'resource URLs missing');
 require(result.events.some(e=>e.document===true &&
 e.request_target==='/?access_token='+demo), 'document event missing');
 for (const expected of [result.query,result.header]) {
 require(result.events.some(e=>e.request_target===expected.request_target &&
 e.authorization_present===expected.authorization_present &&
 e.referer===null), 'matching server event missing');
 }
}
async function readJson(path, options={}) {
 const response=await fetch(path,{...options,redirect:'error',
 signal:AbortSignal.timeout(5000)});
 require(response.ok, 'HTTP status '+response.status);
 return response.json();
}
async function run() {
 require(location.protocol==='http:' && location.hostname==='127.0.0.1',
 'Use the printed loopback URL');
 performance.clearResourceTimings();
 const query=await readJson('/echo?access_token='+demo);
 const header=await readJson('/echo',{headers:{Authorization:'Bearer '+demo}});
 const deadline=performance.now()+5000;
 let resourceUrls=[];
 do {
 resourceUrls=performance.getEntriesByType('resource').map(e=>e.name)
 .filter(name=>new URL(name).pathname==='/echo');
 if (resourceUrls.length>=2) break;
 await new Promise(resolve=>setTimeout(resolve,25));
 } while (performance.now()<deadline);
 const result={page:location.href,query,header,resourceUrls,
 events:await readJson('/events')};
 verifyObservation(result,location.origin);
 window.labResult={status:'PASS',...result};
 document.getElementById('result').textContent=JSON.stringify(window.labResult,null,2);
}
run().catch(error=>{
 window.labError=String(error);
 window.labResult={status:'FAIL',error:window.labError};
 document.getElementById('result').textContent=JSON.stringify(window.labResult,null,2);
});
</script>""").encode()
 kind = "text/html; charset=utf-8"
 else:
 self.send_error(404)
 return
 self.send_response(200)
 self.send_header("Content-Type", kind)
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Referrer-Policy", "no-referrer")
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)


def close_server(server, thread):
 stopper = None
 try:
 if thread.is_alive():
 stopper = Thread(target=server.shutdown, daemon=True)
 stopper.start()
 stopper.join(timeout=3)
 if thread.ident is not None:
 thread.join(timeout=3)
 require((stopper is None or not stopper.is_alive()) and not thread.is_alive(),
 "Server shutdown not verified")
 finally:
 server.server_close()
 require(server.socket.fileno() == -1, "Listener close not verified")
 print(json.dumps({"cleanup": "server thread stopped and listener closed"}), flush=True)


server = LocalServer(("127.0.0.1", 0), Handler)
thread = Thread(target=lambda: server.serve_forever(poll_interval=0.1), daemon=True)
origin = f"http://127.0.0.1:{server.server_port}"
try:
 thread.start()
 with opener.open(origin + "/echo?access_token=" + demo, timeout=5) as response:
 query = json.load(response)
 with opener.open(Request(origin + "/echo", headers={"Authorization": "Bearer " + demo}), timeout=5) as response:
 header = json.load(response)
 require(query["request_target"] == "/echo?access_token=" + demo and
 query["authorization_present"] is False, "query placement mismatch")
 require(header["request_target"] == "/echo" and
 header["authorization_present"] is True, "header placement mismatch")
 events.clear()
 print(json.dumps({"app_url": origin + "/?access_token=" + demo,
 "wire_placement_checks": "PASS", "browser_checks": "NOT RUN BY PYTHON",
 "serve_seconds": args.serve_seconds if args.serve else 0,
 "real_credentials_used": False}), flush=True)
 if args.serve:
 Event().wait(args.serve_seconds)
except KeyboardInterrupt:
 pass
finally:
 close_server(server, thread)

The page requires the printed loopback address, then makes query and header requests with five-second abort signals. Its browser assertions require null received Referer values, exact request targets, both resource-timing URLs, the current page URL, and matching server events. Resource entries get a five-second polling deadline; browser suspension can delay timers. Only then does the page show PASS; missing or mismatched values show FAIL. The current page URL is narrower evidence than a persistent-history audit.

The article reports comparison with browser state and the server event list; no hash-bound browser trace was recovered here. Python checks only request-target placement and the demo-header match. The added browser assertions have not run here; Python output cannot certify them. Runtime and end-to-end technical acceptance remain blocked. The experiment does not test production authentication, TLS termination, log redaction, or signed-link consumption. Apply the observation to the actual client and logging system: keep reusable credentials out of URL surfaces where possible, deliberately protect the remaining credential-bearing fields, and verify the storage and sharing paths that continue after the request finishes.

Sources

RFC 6750 OAuth 2.0 Bearer Token Usage, Authorization header use, query-method limitations, and TLS requirements, checked 2026-09-13.
OWASP information exposure through URL query strings, URL persistence and disclosure through logs and browser records, checked 2026-09-13.
MDN Referrer-Policy, what suppressing referrers does and does not control, checked 2026-09-13.
RFC 9700 OAuth 2.0 Security BCP, query-token prohibition and sender-constrained tokens, checked 2026-10-18.
W3C Resource Timing, resource entries retain the requested URL independently of Referer, checked 2026-10-18.
RFC 9111 HTTP Caching, cache directives and separately implemented application history, checked 2026-10-18.
Python urllib.request, default proxy discovery and explicit opener scope, checked 2026-10-18.
Python socketserver, shutdown must be called from another thread, checked 2026-10-19.
WHATWG Fetch, abort signals and redirect error mode, checked 2026-10-19.
WHATWG DOM, AbortSignal timeout and active-time limits, checked 2026-10-19.

Authentication · XB Field Notes

OAuth code flow trades a code for a token

Public clients can use code flow

Bind the exchange to the original request

When it breaks

Check it quickly

Further reading

Sources

Cookies and sessions hold boundaries

A bearer identifier still carries authority

Two lifetimes need two controls

When it breaks

Check it quickly

Further reading

Sources

SSO delegates authentication; the app still verifies

Identify the protocol and the token

When it breaks

Check it quickly

Give logout its own contract

Sources

Keep reusable access tokens out of request URLs

Distinguish reduced exposure from secrecy

When it breaks

Check it quickly

Sources