Authentication · XB Field Notes

OAuth code flow trades a code for a token

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

Keeping the token on the server and giving the browser only a short-lived code shrinks the surface for token theft in the URL or the log.

The browser gets a code, not a token

The browser is deliberately the wrong place for the access token. In the authorization-code flow the browser goes to the authorization server, sees the consent screen, and comes back at the redirect URI carrying only a short authorization code, never the token. The token stays off the browser’s URL history and out of its logs, because it is the backend that presents the code together with the client secret to the token endpoint. That split of labour — the browser carries the code, the server owns the secret — is the entire point of the flow.

The backend does the exchange

The exchange happens server-side, so the access token is minted and kept where the browser’s history cannot log it and a client-side bug cannot leak it. The backend sends the code, its client secret, and its redirect_uri to the token endpoint, getting a JSON access token (and optionally a refresh token) that never passed through the browser. This is what makes public clients (a native or SPA) a liability in this flow: they cannot hold a client secret, so the code flow is the right choice only for confidential clients. The trade the code flow makes is a server round-trip in exchange for never exposing the token to the user agent.

Code is one-shot and short-lived

A correct code is single-use and short-lived, so it removes replay and live-window risk at once. If the code is intercepted, it cannot be reused for a second exchange; if it sits unused, it expires on its own within its short lifetime. Two protections make that airtight: bind the code to the exact redirect_uri that was used in the original request (PKCE adds a verifier so an intercepted code is worthless without the client-held code_verifier), and store codes with an expiry. Code is the currency that trades once — treat its one-shotness as a contract, not guidance.

When it breaks

A leaked code works like a short-lived password. Codes show up in access logs, history, Referer headers, or crash reports when the full callback URL is logged or served over plain HTTP. Reusable or long-lived codes let anyone who copies the string exchange it first. Keep codes out of logs, serve redirects over TLS, expire them in minutes, and burn each code on first use.

Loose redirect_uri checking delivers codes to attackers. A server that accepts prefix matches or unlisted hosts hands the victim’s code to a lookalike domain. Pre-register every redirect URI, compare the authorize and token values with exact equality, and reject the exchange on any mismatch.

Missing PKCE exposes public clients. A mobile or single-page app has no client secret, so an intercepted code alone suffices when no code_challenge was required. The sign is an authorize request without a challenge, or a server that accepts plain instead of S256. Send only the SHA-256 challenge and reject verifiers that do not reproduce it.

Static refresh tokens prolong the breach. Without rotation, one stolen token mints access tokens indefinitely, and without reuse detection parallel uses both succeed. Rotate the refresh token on every exchange, chain each generation to its predecessor, and revoke the family when a used token reappears.

Check it quickly

Save the following as oauth_code_demo.py and run python3 oauth_code_demo.py. It models one authorization server in memory with only hashlib, secrets, and base64, so nothing leaves the machine and no network account is needed. The script mints one code bound to a redirect URI and an S256 challenge, then exercises the exchange.

import base64
import hashlib
import secrets


def make_challenge(verifier: str) -> str:
 digest = hashlib.sha256(verifier.encode("utf-8")).digest()
 return base64.urlsafe_b64encode(digest).rstrip(b"=").decode("ascii")


CODES: dict[str, dict] = {}


def authorize(code: str, challenge: str, redirect_uri: str) -> None:
 CODES[code] = {"challenge": challenge, "redirect_uri": redirect_uri, "used": False}


def exchange(code: str, verifier: str, redirect_uri: str) -> str:
 entry = CODES.get(code)
 if entry is None:
 raise AssertionError("unknown code")
 if entry["used"]:
 raise ValueError("code already used")
 if redirect_uri != entry["redirect_uri"]:
 raise ValueError("redirect_uri mismatch")
 if make_challenge(verifier) != entry["challenge"]:
 raise ValueError("PKCE verifier mismatch")
 entry["used"] = True
 return "access-token-" + secrets.token_hex(4)


verifier = secrets.token_urlsafe(32)
challenge = make_challenge(verifier)
redirect = "https://app.example/callback"
authorize("code-one", challenge, redirect)
token = exchange("code-one", verifier, redirect)
assert token.startswith("access-token-")

try:
 exchange("code-one", verifier, redirect)
 raise AssertionError("replay should have been rejected")
except ValueError as exc:
 assert str(exc) == "code already used"

authorize("code-two", challenge, redirect)
try:
 exchange("code-two", "wrong-verifier", redirect)
 raise AssertionError("wrong verifier should have been rejected")
except ValueError as exc:
 assert str(exc) == "PKCE verifier mismatch"

try:
 exchange("code-two", verifier, "https://evil.example/callback")
 raise AssertionError("wrong redirect should have been rejected")
except ValueError as exc:
 assert str(exc) == "redirect_uri mismatch"

print("PASS: one-time code, S256 PKCE, and exact redirect_uri all enforced; replay refused")

The first exchange with the correct verifier and exact redirect URI succeeds and returns a token. Replaying the same code fails because the server marks it used, and exchanging with the wrong verifier or a mismatched redirect URI also fails. The assertions encode exactly that contract, and the final line prints PASS. The demo omits client authentication, expiry clocks, and persistent storage, which a production review must still verify.

Sources

RFC 6749 authorization code flow, defines the code flow, checked 2026-03-02.
RFC 7636 PKCE for OAuth public clients, code verifier and S256 challenge, checked 2026-03-02.
OWASP OAuth2 Cheat Sheet, redirect validation, PKCE, and token storage guidance, checked 2026-03-02.

Cookies and sessions hold boundaries

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

The browser holds a cookie and the server holds the state the cookie stands for. Confusing the two — or letting the cookie carry more meaning than it should — is where authentication bugs start.

A session cookie is usually a high-entropy random value the server mints, stores server-side, and later looks up to find the matching session. It exists only as a pointer: the cookie identifies a session; the session holds the authority. That split matters because the browser sees and can re-send the cookie verbatim on every request, so putting meaningful data inside it — a user id, a role, an email — means giving the client every value it would need to forge or tamper with state. Keep the cookie opaque: a long random string with no structure the client is meant to read, and let the server resolve it to the actual privileges.

Define the attributes honestly

Each cookie attribute is a distinct boundary and must be set deliberately, not left to a browser default. Secure restricts transmission to HTTPS so the value is not sent in the clear; HttpOnly stops JavaScript from reading it via document.cookie, which neutralizes the most common XSS payload; SameSite controls whether the cookie is attached to a cross-site request — Lax for most sites, Strict where a session must never ride requests from another origin; and Max-Age/Expires bounds how long the token lives. A short, session-scoped life with rotation on privilege changes is the honest default. Set each one explicitly because each default the browser chooses is a policy you did not choose.

The session is the server’s obligation

The cookie is only the pointer; the server owns the session and must decide how long it lives, when it is idle-expired, and what causes it to be invalidated. Bind the session to real signals: an absolute expiry so a session does not live forever, an idle timeout so an abandoned tab cannot be resumed weeks later, and server-side revocation — delete or mark the session when the user logs out so the cookie becomes a dud rather than a standing key. Because the token can still be exfiltrated, also rotate it after login and privilege change. When the cookie stays opaque and the server enforces these rules, the pair remains a small, honest contract rather than a time bomb.

When it breaks

A broad Domain turns one bug into every subdomain’s problem. With Domain=example.com, the session rides to static hosts and logs that never needed it, so XSS on a forgotten subdomain replays the main login. A shallow Path=/ leaks the same way inside one host, and Path never replaces server-side authorization.

Fixation is the second break. If the server accepts an attacker-planted id or keeps the pre-login value after authentication, that value owns the later login. Without absolute expiry, idle timeout, and logout revocation, the cookie stays a standing key. Add SameSite=None without Secure, or leave state changes on GET, and a cross-site request carries the cookie exactly when it should not.

Bloat fails quietly. Roles or a JWT in the cookie push it past about four kilobytes or the eight-kilobyte header limit, so real requests die with 400 or 431 while every request pays the weight. Missing Secure leaks on plain HTTP; missing HttpOnly hands the value to any injected script.

Check it quickly

Save the snippet as cookie_boundary_demo.py and run python3 cookie_boundary_demo.py. It uses only http.cookies, opens no sockets, and writes no files. Each Set-Cookie string is parsed into domain, path, and flags, then should_send decides whether a host, path, and transport would receive it.

from http.cookies import SimpleCookie


def parse(header: str) -> dict:
 jar = SimpleCookie()
 jar.load(header)
 name = next(iter(jar))
 m = jar[name]
 return {
 "name": name,
 "value": m.value,
 "domain": m["domain"].lstrip(".").lower(),
 "path": m["path"] or "/",
 "secure": bool(m["secure"]),
 "httponly": bool(m["httponly"]),
 "samesite": (m["samesite"] or "Lax").lower(),
 }


def domain_ok(cookie_domain: str, host: str) -> bool:
 host = host.lower()
 return host == cookie_domain or host.endswith("." + cookie_domain)


def path_ok(cookie_path: str, req_path: str) -> bool:
 if req_path == cookie_path:
 return True
 if req_path.startswith(cookie_path):
 if cookie_path.endswith("/"):
 return True
 if len(req_path) > len(cookie_path) and req_path[len(cookie_path)] == "/":
 return True
 return False


def should_send(cookie: dict, raw_domain: str, origin: str,
 host: str, req_path: str, is_https: bool) -> bool:
 if not raw_domain:
 if host.lower() != origin.lower():
 return False
 elif not domain_ok(cookie["domain"], host):
 return False
 if not path_ok(cookie["path"], req_path):
 return False
 if cookie["secure"] and not is_https:
 return False
 if cookie["samesite"] == "none" and not cookie["secure"]:
 return False
 return True


def check(cond: bool, msg: str) -> None:
 if not cond:
 raise AssertionError(msg)
 print(f"ok: {msg}")


ORIGIN = "app.example.com"
good = parse("sid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600")
check(good["secure"] and good["httponly"] and good["samesite"] == "lax",
 "good cookie carries Secure/HttpOnly/SameSite=Lax")
check(should_send(good, "", ORIGIN, ORIGIN, "/dashboard", True),
 "host-only cookie sent to same host over HTTPS")
check(not should_send(good, "", ORIGIN, "evil.com", "/dashboard", True),
 "host-only cookie rejected for evil.com")
check(not should_send(good, "", ORIGIN, ORIGIN, "/dashboard", False),
 "Secure cookie rejected over plain HTTP")

broad = parse("sid=abc123; Domain=example.com; Path=/; Secure; HttpOnly; SameSite=Lax")
check(should_send(broad, "example.com", ORIGIN, "shop.example.com", "/", True),
 "Domain=example.com reaches subdomain")
check(not should_send(broad, "example.com", ORIGIN, "evil.com", "/", True),
 "Domain cookie rejected for evil.com")
check(not should_send(broad, "example.com", ORIGIN, "example.com.evil.com", "/", True),
 "suffix trick example.com.evil.com rejected")

admin = parse("adm=1; Path=/admin; Secure; HttpOnly; SameSite=Strict")
check(should_send(admin, "", ORIGIN, ORIGIN, "/admin/users", True),
 "Path=/admin sent under /admin/users")
check(not should_send(admin, "", ORIGIN, ORIGIN, "/public", True),
 "Path=/admin rejected for /public")

bad = parse("sid=leaked; SameSite=None")
check(bad["samesite"] == "none" and not bad["secure"],
 "SameSite=None without Secure detected")
check(not should_send(bad, "", ORIGIN, ORIGIN, "/", True),
 "browser would drop SameSite=None without Secure")

plain = parse("pref=light; Path=/; Secure; SameSite=Lax")
check(not plain["httponly"], "missing HttpOnly is visible to document.cookie")
check(len("a=" + "x" * 5000) > 4096, "oversized cookie detected (5002 bytes > 4096)")

print("PASS: 13 checks; out-of-scope Domain/Path and insecure transport rejected")

Thirteen checks cover those boundaries. A host-only cookie reaches its own host over HTTPS but is refused for evil.com and plain HTTP. A Domain=example.com cookie reaches a subdomain yet rejects evil.com and example.com.evil.com. A Path=/admin cookie stays under /admin/users and is refused for /public. SameSite=None without Secure is flagged as dropped, missing HttpOnly is reported as script-readable, and an oversized value trips the size warning. Expect PASS: 13 checks; out-of-scope Domain/Path and insecure transport rejected. The demo checks matching rules, not browser storage or your logout path, so repeat the probes against a real response before shipping.

Sources

MDN: Using the Fetch / HTTP cookies, attributes and scope, checked 2027-01-10.
OWASP: Session Management, session identifiers and their lifecycle, checked 2027-01-10.
RFC 6265: HTTP State Management, the Set-Cookie attributes, checked 2027-01-10.

SSO is a relay, not a password

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

Single sign-on is a relay, not a password handover. The user proves their identity to an identity provider once, and that provider hands each app a signed assertion or token. The app never stores a password; it stores the provider’s public key, the issuer it expects, and the audience it answers to.

That division of labour is the whole design, and it moves the risk rather than removing it. The app’s security now rests entirely on verification steps it can skip by accident, and the token becomes the thing worth stealing.

Three parties, two encodings

SAML and OIDC are the same relay in two encodings: an XML assertion with an XML-DSig signature, or a JSON Web Token with a JWS signature. Both carry an issuer, a subject, an audience and an expiry, and both are verified against metadata the provider publishes — a signing certificate or a JWKS endpoint. OIDC Core is explicit about two of the checks: the issuer identifier from discovery must exactly match the iss claim, and the token must be rejected if the audience does not list the client.

The audience check is what stops a relay from becoming a skeleton key. A token minted for the analytics dashboard is a valid, correctly signed token — and the billing app must still refuse it. That is why aud is not a formality: without it, every app that trusts the same provider can be entered with a token issued for any other app.

Verification is four checks, not one

The signature is only the first check, and it must be made over the exact received bytes with an algorithm the app chose, never one the token named. RFC 8725 documents both classic failures: an attacker changing alg to none so a library skips verification, and changing RS256 to HS256 so a library HMACs with the RSA public key as the shared secret. In the run behind this note an unsigned token and an HS256 token keyed with the public key were both accepted by a verifier that read alg from the header, and both rejected by a verifier that pinned RS256 in configuration.

Then come the claims. A payload byte flipped in transit failed the signature check. A token with exp an hour in the past still verified cryptographically and was rejected on its claims — the signature says the token is authentic, not that it is current. RFC 7519 allows “some small leeway, usually no more than a few minutes” for clock skew, and 30 seconds of skew was accepted under a 60-second leeway. Finally the jti is checked against a revocation list, because a signature that verifies says nothing about whether the session should still exist.

What the relay cannot do for you

Revocation is the part SSO does not solve by itself. Logging out of the provider ends the provider’s session; the app’s own session lives until its token expires unless the app actively ends it. A short exp with a refresh token, plus back-channel logout or token introspection, is what closes the loop. Relying on the provider alone leaves a window measured in the token’s lifetime, and that window is the whole exposure.

When it breaks

The first failure is a relay that trusts without checking. A misconfigured library that honours the alg header, or an assertion whose signature is never validated because it arrived over TLS, accepts anything — including a forged sub naming an administrator. It presents as a working login, which is why it survives review: nothing errors, and there is no password database whose emptiness would give the gap away.

The second is time and revocation. Clocks that disagree beyond the leeway make every freshly issued token look not yet valid or already expired, an outage that looks like a provider problem and is really NTP. A generous leeway hides that by widening the window in which a revoked token still works. And an offboarded employee whose provider account is disabled keeps their app session until it expires, which is the difference between minutes and days.

Check it quickly

Decode the token before trusting it:

python3 -c 'import base64,json,sys; b=sys.argv[1].split("."); d=lambda s: base64.urlsafe_b64decode(s+"="*(-len(s)%4)); print(json.loads(d(b[0])))' "$TOKEN"
python3 -c 'import base64,json,sys,time; b=sys.argv[1].split("."); d=lambda s: base64.urlsafe_b64decode(s+"="*(-len(s)%4)); p=json.loads(d(b[1])); print(p["iss"], p["aud"], p["exp"]-int(time.time()))' "$TOKEN"
curl -s https://idp.example.com/.well-known/openid-configuration | jq -r '.issuer, .jwks_uri'

The header should name RS256 or ES256 — none, HS256 and an unexpected kid are the findings, not the noise. The second line prints the issuer, the audience and the seconds until expiry: a negative number means the token is already expired, and an audience that is not your client id means it was minted for something else. The issuer from the metadata must match the iss claim byte for byte.

Sources

RFC 7519: JSON Web Token, the registered claims and the leeway allowed for clock skew, checked 2026-09-16.
RFC 8725: JWT Best Current Practices, alg=none and the RS256-to-HS256 confusion attack, checked 2026-09-16.
OpenID Connect Core 1.0, ID Token validation, issuer matching and the audience requirement, checked 2026-09-16.

Keep reusable access tokens out of request URLs

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

A reusable access token grants whoever possesses it some defined access. 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, the Authorization header is the recommended general mechanism. 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.

Check it quickly

Save this as token-placement.py, run python3 token-placement.py --serve, and open its printed page. Python 3.14.4 and Chrome 152 were used. 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. Control-C closes it.

import json
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.parse import urlsplit
from urllib.request import Request, urlopen

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


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"
 else:
 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) + """;
async function run() {
 const query=await (await fetch('/echo?access_token='+demo)).json();
 const header=await (await fetch('/echo',{headers:{Authorization:'Bearer '+demo}})).json();
 await new Promise(resolve=>requestAnimationFrame(resolve));
 const resourceUrls=performance.getEntriesByType('resource').map(entry=>entry.name).filter(name=>name.includes('/echo'));
 window.labResult={page:location.href,query,header,resourceUrls};
 document.getElementById('result').textContent=JSON.stringify(window.labResult,null,2);
}
run().catch(error=>{window.labError=String(error);});
</script>""").encode()
 kind = "text/html; charset=utf-8"
 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)


server = HTTPServer(("127.0.0.1", 0), Handler)
thread = Thread(target=server.serve_forever, daemon=True)
thread.start()
origin = f"http://127.0.0.1:{server.server_port}"
try:
 with urlopen(origin + "/echo?access_token=" + demo, timeout=5) as response:
 query = json.load(response)
 with urlopen(Request(origin + "/echo", headers={"Authorization": "Bearer " + demo}), timeout=5) as response:
 header = json.load(response)
 assert demo in query["request_target"] and query["authorization_present"] is False
 assert demo not in header["request_target"] and header["authorization_present"] is True
 events.clear()
 print(json.dumps({"app_url": origin + "/?access_token=" + demo,
 "wire_placement_checks": "PASS", "real_credentials_used": False}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 server.shutdown()
 thread.join(timeout=5)
 server.server_close()

The page makes one request with an access_token query and another with an Authorization header. Both have null received Referer values because the page sends no-referrer. Nevertheless, the query request’s target contains the marker, while the header request’s target is simply /echo. The browser’s resource timing URLs show the same distinction. The page address itself also contains the marker, so its current navigation entry retains that URL.

Those results were checked against both browser state and the server’s synthetic event list. The Python-only probe separately confirms the request-target difference. 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.

Authentication · XB Field Notes

OAuth code flow trades a code for a token

The browser gets a code, not a token

The backend does the exchange

Code is one-shot and short-lived

When it breaks

Check it quickly

Further reading

Sources

Cookies and sessions hold boundaries

Define the attributes honestly

The session is the server’s obligation

When it breaks

Check it quickly

Further reading

Sources

SSO is a relay, not a password

Three parties, two encodings

Verification is four checks, not one

What the relay cannot do for you

When it breaks

Check it quickly

Sources

Keep reusable access tokens out of request URLs

Distinguish reduced exposure from secrecy

When it breaks

Check it quickly

Sources

Authentication · XB Field Notes

OAuth code flow trades a code for a token

The browser gets a code, not a token

The backend does the exchange

Code is one-shot and short-lived

When it breaks

Check it quickly

Further reading

Sources

Cookies and sessions hold boundaries

The cookie is an identifier, not the authority

Define the attributes honestly

The session is the server’s obligation

When it breaks

Check it quickly

Further reading

Sources

SSO is a relay, not a password

Three parties, two encodings

Verification is four checks, not one

What the relay cannot do for you

When it breaks

Check it quickly

Sources

Keep reusable access tokens out of request URLs

Distinguish reduced exposure from secrecy

When it breaks

Check it quickly

Sources