An OAuth callback proves who logged in, not what the patient agreed to

Retries are where this design earns its keep. The write-up frames consent as an exactly-once business effect sitting on top of operations that may execute more than once, because network delivery never promised a single attempt ^[21]. So the durable work is one transaction: insert the idempotency claim, append the consent event, update the current projection ^[10]. The caller that loses the race on the key reads and returns the committed result instead of manufacturing a second audit event ^[10]. Repeated submission of the same decision under the same key has exactly one durable effect ^[6]. The audit writer lives in that transaction too; an asynchronous best-effort log is fine for analytics and cannot be the evidence ^[17].

The part worth drawing on a whiteboard is the state table this produces. Authentication status is a boolean, but consent has three positions: absent, current, or superseded by a newer policy revision, since a revision appends a new record rather than editing the old one ^[7]. That is six combinations, and two of them are authenticated sessions that must still be refused protected patient data ^[1]. The source says as much directly: a session can be authenticated and barred because current consent is absent ^[8]. A single success flag has one position and therefore cannot represent either of those two ^[4]. Counted in stored values, the honest record is at least six fields per decision against that flag's one ^[2].

The browser sits outside the trust boundary for anything durable ^[13]. It can carry an opaque state value through the authorization redirect, but the server binds that state to the intended session and validates the returned flow before a local session exists ^[13]. Consent is then collected on a portal-controlled screen whose policy version the server selects ^[14]. That is the mechanism behind the argument against a checkbox riding along with the callback: it merges two state machines and leaves the portal unable to prove which rendered text the patient actually saw ^[15].

Recovery is treated as a separate lane, which is the detail most portals get wrong during a provider migration. The forgot-password response is uniform so account existence is not disclosed, while the internal trail keeps a correlation identifier and a coarse outcome and not the reset secret ^[18]. Regaining account access grants, refreshes and implies nothing about consent ^[9]. Sessions get invalidated or reassessed afterwards and reauthentication is required before sensitive account changes, none of which touches a prior consent record ^[19]. If identity keys change on the way off a managed provider, an explicit mapping from the old identifier has to be preserved ^[20], and both claims, identity and consent, have to survive the move independently ^[1].

One caveat on the sourcing. This is an engineering argument, published on dev.to, and its authority is the auditability constraint it states rather than a rule anyone has quoted ^[2]. It reaches for OWASP only on the narrow point that authentication responses and reauthentication are security-sensitive behavior ^[12], and it names no statute, regulator or enforcement action. It also declines to collect authorization codes, access tokens, reset secrets or full request bodies into the audit payload ^[11], which is the right call and does narrow what a later investigation can replay. Nobody has costed the schema, the backfill or the migration mapping. That bill is real and unquantified here.