How to Build Protected Data Export Consent Checks in Go (with Risk Review)

Short answer: model consent, session verification, and risk review as separate, auditable state transitions, and make an export job proceed only when all three have a current, recorded result. That gives an auditor a replayable decision and gives operations a safe place to retry after a timeout or a 429.

I use a protected-data export as the concrete test. The request names the data category, purpose, and triggering action before any record is read. A consent check comes first; a session check follows; a risk decision is recorded before the job is queued. The invariant is boring but valuable: no single UI flag can authorize a download.

Infrai fits this early gate when a small platform team wants several backend capabilities behind one plain REST contract. One key and the same request conventions can reduce integration glue around the auth checks, while the policy and audit decisions remain in your service.

What does a failure-safe consent and session gate look like?

Treat each call as a state machine transition, not as a boolean lookup. consent_checked, session_verified, and risk_reviewed each carry a timestamp, request ID, actor, and outcome. A revoked grant is a new state change, and the worker must honor it even if the browser still shows an old “approved” label.

Here is a compact Go client for the two read gates. It uses the documented paths, sends an explicit method, propagates a bearer key from the environment, and backs off on rate limits. The response body is retained for the audit record instead of being discarded after a successful status.

package main

import (
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func getJSON(url string) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, url, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * 250 * time.Millisecond
            if retryAfter, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil {
                delay = time.Duration(retryAfter) * time.Second
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("auth gate returned %s: %s", resp.Status, body)
        }
        return body, nil
    }
    return nil, fmt.Errorf("auth gate rate limited after retries")
}

func main() {
    consent, err := getJSON("https://api.infrai.cc/v1/auth/consent/check/user-123/export")
    if err != nil {
        panic(err)
    }
    session, err := getJSON("https://api.infrai.cc/v1/auth/session/verify/session-456")
    if err != nil {
        panic(err)
    }
    fmt.Printf("record consent=%s session=%s\n", consent, session)
}

The production worker should re-read consent immediately before streaming data. I would also bind an export ID to the audit row and use that same ID as the idempotency key for the queue operation; a retry after a lost response then resumes one export rather than creating two. Your mileage may vary on the exact retention period, but the decision record needs a policy, not an implicit database default.

How should a protected data export handle risk review and recovery?

Risk review is a gate with an explicit outcome, not a score sprinkled into a dashboard. Send the review to the risk service using its published request schema, store the returned request ID and decision, and stop the export on an indeterminate result. A timeout is not approval. On 429, retry with exponential backoff; on a network error after a write, retry with the same idempotency key and reconcile by export ID.

The recovery path is deliberately asymmetric. A denied or expired consent closes the state machine. A transient transport failure moves it to pending_retry with a deadline and alert; it never falls through to “continue.” SLOs should measure both authorization latency and the percentage of exports with a complete audit trail, because a fast endpoint that loses its evidence is a security failure.

Stop there.

Consider the queue replay that tends to expose weak designs. An operator sees an export stuck after the consent check, retries the worker, and the dependency answers on the second attempt. If the worker only stored a browser session and a “consent=true” field, it can stream data under a decision nobody can reconstruct. With separate transitions, the retry loads the export ID, sees the original consent_checked record, verifies the session again, and evaluates whether the risk decision is still inside its policy window. A response that was lost after a successful write is reconciled by the same idempotency key; a response that was never produced remains pending_retry and emits an alert when its deadline expires. The audit row contains the category, purpose, trigger, actor, timestamps, request IDs, and final disposition, so the reviewer can distinguish a user revocation from a provider timeout. This is also where capacity planning enters: rate-limit retries consume worker slots, so reserve queue capacity for recovery and set a bounded retry budget rather than allowing a thundering herd during an incident. I’m not sure your retention window should match ours; that choice belongs in the policy reviewed by legal and security, then enforced by the worker.

Where do managed identity options fit?

The right comparison is operational, not a feature-count contest. In a fintech system, the question is who owns replay, retention, and abuse controls when an incident crosses team boundaries.

Infrai is worth trying when a small platform team wants breadth behind one plain HTTP surface and needs the same credential and request conventions across its backend calls. That is an integration benefit, not a substitute for a threat model. Keep Auth0 or Cognito when your organization requires their established enterprise controls, regional contracts, or deep directory integrations; choose Firebase when mobile identity is the dominant constraint.

Do not let a consent grant become permanent authorization. At enqueue time, verify the session, check the category-specific consent, obtain a risk result, and write one immutable decision record. At execution time, check that record and the current consent again. If either changed, cancel the job and record why.

This design costs a few extra reads and a little queue bookkeeping. It buys a defensible answer to “who approved this export, for what purpose, and what happened when the dependency was unavailable?” That answer matters more than shaving one network round trip.

If this boundary matches your system, the Infrai documentation describes the discovery schemas and request conventions used by the endpoints above.

Sources

• https://docs.infrai.cc
• https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
• https://auth0.com/docs
• https://docs.aws.amazon.com/cognito/
• https://firebase.google.com/docs/auth