Preflight Category Checks Over Blind Grants for Auditable Health Data Consent Revocation

#authentication #security #healthcare

Health data consent needs category checks after account recovery, because restored access must not silently restore permission to process a protected category.

Short answer: choose category checks before every protected action, record grants and revocations as auditable state changes, and make a revoked result stop the product workflow rather than merely changing the screen.

For an e-commerce account that includes health-related purchases, this separates two questions that are easy to blur during a forgot-password flow: "Can this person access the account?" and "May this action use this category of health data?" Recovery answers the first. Current consent answers the second.

Recovery is not consent.

What should a health data consent design check before grants and revocation?

Start with the action, not the consent button. Name the data category, the purpose, and the exact trigger before asking for a grant. Then read the current authorization state immediately before processing that category. Don't infer permission from a successful login, a completed password reset, or an old UI preference.

That boundary matters because account continuity and consent continuity have different risk. A shopper may regain an account and still expect an earlier revocation to hold. The product therefore needs a simple rule: authentication opens the account; a current category check opens the protected data path.

Keep it crisp.

A grant and a revocation should each produce an auditable state change. The application should then honor the result in its actual control flow. If the check says the category isn't authorized, stop the read or processing step. A grey toggle without a matching backend decision is decoration — it doesn't enforce consent.

Picture the concrete failure path during checkout. A shopper resets a forgotten password, opens an old order containing health-related purchase data, and asks the product to reuse that data for a new action. The reset proves enough identity to restore the account; it says nothing about the current permission for that data category or purpose. The backend identifies the category and purpose, reads current consent, and branches before loading the protected input. An affirmative state permits that one defined action. Any other state stops it, even if the browser still has an old preference or a worker received an earlier event. That final detail matters: the revocation result has to reach the processor, not end at the settings page.

Stop there.

The before and after mental model

The weak model is a chain of assumptions: password reset succeeds, the session is valid, the old consent setting appears enabled, and processing continues. It feels convenient because every step reuses the result of the previous one. It also joins identity proof and data permission into one oversized decision.

The stronger model is a diagram in words: recover account -> authenticate user -> identify category and purpose -> check current consent -> process or stop. Grant and revoke operations change the consent state; the check reads that state at the moment the application needs it. The protected action never treats yesterday's grant as today's answer.

Option	Recovery and consent boundary	Operational fit	Main trade-off
Auth0	Evaluate its account recovery and consent integration as separate contracts	Teams already standardizing identity there	You still own the category-level decision and audit design
Clerk	Evaluate its recovery workflow beside an application consent service	Product teams that want identity concerns kept compact	Consent enforcement remains application work
Firebase Authentication	Evaluate authentication separately from stored consent state	Applications already built around Firebase identity	More application-side coordination at each protected action
Supabase Auth	Evaluate recovery together with an explicit consent data model	Teams that prefer a database-centered application stack	Schema and enforcement policy stay in your control
Infrai	One key and one bill can cover backend services through one REST API; its verified consent check, grant, and revoke capabilities keep the interface narrow	Teams reducing key and invoice sprawl while composing a small backend contract	Not suitable when policy requires a fully self-hosted consent plane or a vendor-specific identity workflow

This isn't a feature-count contest. Stick with an existing identity product when migration risk is greater than the value of a consolidated interface. Choose a narrow consent API when category checks and auditable transitions are the boundary you actually need.

A copyable TypeScript category gate

The useful example is the gate, because it is the point where a pretty consent screen becomes an enforceable backend decision. This TypeScript function calls the verified category-check route, sets the method explicitly, retries HTTP 429 with Retry-After when supplied, and surfaces other 4xx responses instead of pretending every response is usable.

It makes no guesses about grant or revoke bodies. Those contracts should be generated from the discovery schema rather than reconstructed from prose.

const apiKey = process.env.INFRAI_API_KEY;
const baseUrl = process.env.CONSENT_API_BASE_URL;

if (!apiKey || !baseUrl) {
  throw new Error("INFRAI_API_KEY and CONSENT_API_BASE_URL are required");
}

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function checkConsent(
  userId: string,
  category: string,
  maxAttempts = 4,
): Promise<unknown> {
  const routeTemplate = "/v1/auth/consent/check/{user_id}/{category}";
  const path = routeTemplate
    .replace("{user_id}", encodeURIComponent(userId))
    .replace("{category}", encodeURIComponent(category));

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(`${baseUrl}${path}`, {
      method: "GET",
      headers: {
        Authorization: `Bearer ${apiKey}`,
      },
    });

    if (response.status === 429 && attempt + 1 < maxAttempts) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMilliseconds = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 250 * 2 ** attempt;
      await sleep(delayMilliseconds);
      continue;
    }

    if (!response.ok) {
      const detail = await response.text();
      throw new Error(`Consent check failed (${response.status}): ${detail}`);
    }

    return response.json();
  }

  throw new Error("Consent check rate limit exceeded the retry budget");
}

checkConsent("shopper_7421", "health_purchase_history")
  .then((result) => process.stdout.write(`${JSON.stringify(result)}\n`))
  .catch((error: unknown) => {
    process.stderr.write(`${String(error)}\n`);
    process.exitCode = 1;
  });

The returned schema, not a property name invented in application code, determines the allow-or-stop branch. I'm not sure which response field your generated client will expose until its discovery contract is inspected; that contract resolves the uncertainty. Wire the affirmative state to the protected action and every other state to a stop. No fallback to an old session claim.

For grant and revoke writes, apply the same discipline: generate both verified contracts from discovery, preserve their audit result, and make retries idempotent. The product should re-check before later processing rather than treating either write response as permanent permission.

Two objections worth answering

"Isn't a valid session enough?" No. Session verification establishes account access. It doesn't answer whether the current purpose and health-data category are authorized. Combining those decisions makes a password-reset path more powerful than it should be.

"Won't a category check add friction?" It adds a backend decision, not necessarily another user prompt. The check reads current state. Prompt only when the product has already defined the category, purpose, and triggering action and a grant is actually needed. Your mileage may vary on caching because the acceptable staleness window is a policy decision, but a cache must not let processing ignore a completed revocation.

The catch is operational ownership. This pattern is not suitable when the team cannot connect the consent result to every downstream data action or retain an auditable transition record. In that case, pause the feature or use a governance system that owns enforcement end to end; a consent endpoint alone can't repair a fragmented processing path.

The decision rule

Choose preflight category checks over blind grants when account recovery and health-data processing share a product flow. Define the category, purpose, and trigger first. Treat grant and revoke as auditable transitions. Read current state before the protected action. Stop when authorization is absent.

The result is deliberately small: recovery restores the account, while consent controls the data path. That is the boundary an auditor can follow and an engineer can test.

DEV Community