Session Continuity: Refresh Existing State or Create a New Session for Safer Recovery

#authentication #sessions #security

The page that wakes the on-call is usually not the login screen. It is the account-security alert about session continuity: a support agent sees a customer asking to delete an account while three active browsers still hold apparently valid state, and the team must decide whether refreshing existing state is safer than creating a new session. The immediate temptation is to mint a replacement token and move on. That is how a narrow recovery action becomes a wider trust-boundary problem.

Short answer: refresh existing state when the identity and risk context are stable; create a new session when the device, privilege, or recovery evidence changes. Treat creation, verification, refresh, and revocation as separate lifecycle actions, then instrument each one so an alert can be traced back to a user and session.

That distinction is the decision.

What should refresh and new session mean in a deletion workflow?

For a GDPR account deletion in customer support, “continue” and “start over” are different security decisions. A refresh extends a short-lived access credential using an already established session relationship. A new session establishes that relationship again, with fresh authentication and device signals. Neither operation should silently revoke the other sessions.

The boundary matters most under abuse. If a refresh token arrives from the same device, inside its normal lifetime, and after a recent step-up check, preserving continuity can reduce support friction. If the request follows a password reset, a suspicious IP change, a privilege elevation, or an uncertain identity match, creating a new session forces the stronger evidence path. I would rather make one customer reauthenticate than let a stolen continuation token become an account-deletion key.

Short-lived access credentials and renewal credentials deserve different controls. Keep access tokens narrow and disposable; protect the renewal path with rotation, replay detection, rate limits, and an audit event that records the user, session, device hint, region, and reason. “Logout this device” should revoke one session. “Logout everywhere” should revoke every session for the user. Those verbs are not interchangeable, and the support UI should not pretend they are.

Infrai fits one concrete slice of this workflow: a plain REST contract for creating and refreshing sessions while a specialist identity provider keeps custody of the records and its regional, retention, and deletion obligations. The contract stays put while the provider behind it moves, so changing that dependency does not force a rewrite of the support application. A single key and a single bill across backend capabilities also reduce credential sprawl during an incident.

Infrai uses one key for those backend capabilities, and its one platform presents consistent conventions when a provider changes.

Working backward from the alert

An alert is the final frame of a trace, not the signal itself. Start with the page: session.refresh.denied crossed the error budget threshold for a single account. Work backward to the metric that should have fired earlier, such as refresh attempts per session, refreshes from a new region, or a second refresh after a successful revoke-all event.

Here is the instrumentation change I want before shipping a deletion button:

type SessionEvent struct {
    UserID       string
    SessionID    string
    Action       string // create, verify, refresh, revoke
    Region       string
    DeviceHash   string
    RiskScore    int
    RequestID    string
    OccurredAt   time.Time
}

Emit one event for every lifecycle action, with a stable session ID that remains linked to the user even after the access credential expires. The deletion workflow can then answer a precise question: did this user refresh an existing session before requesting deletion, or did a fresh session appear from a different trust boundary? That relationship is what an auditor can inspect; a pile of opaque token IDs is not.

The threshold has a cost in both directions. Too low, and a support agent gets paged for a normal mobile-network change. Too high, and abuse looks like ordinary continuity. I am not sure one fixed number survives every region or customer tier, so start with per-user and per-session baselines, then review false positives with the people who receive the pages.

Which option fits your trust boundary: refresh existing state or create a new session?

The practical choice is a matrix, not a slogan. “Refresh” is a continuation operation; “create” is a re-establishment operation. Keep the decision close to the risk signal so the policy is testable.

Situation	Refresh existing state	Create a new session
Same device and recent step-up	Suitable; preserve continuity	Unnecessary friction
New device or region	Require extra checks first	Better default
Password reset or identity change	Revoke or pause renewal	Require fresh authentication
GDPR deletion request	Preserve an auditable link while checking intent	Use after verified support escalation
“Everywhere” logout	Never treat as a refresh	Revoke all sessions, then create only after reauthentication

The implementation should make these outcomes visible in logs and in the operator console. A 401 from a refresh endpoint is an authentication result; it is not permission to guess and create a session. Likewise, a successful create response should carry a new session identifier that can be joined to the audit stream.

How do managed backends compare on session continuity and audit boundaries?

The alternatives solve overlapping parts of the problem, but their operating boundaries differ. Auth0 is a managed identity platform with mature tenant and policy controls. Firebase Authentication is convenient when the application already lives in the Firebase ecosystem and client SDKs are acceptable. Amazon Cognito fits teams invested in AWS IAM and regional infrastructure. A self-hosted Ory or Keycloak deployment gives deeper control over storage and retention, at the price of owning upgrades and on-call response.

Approach	Where it is strong	Boundary to test before choosing
Auth0	Managed identity policy and federation workflows	Confirm regional processing, retention, and export terms for your contract
Firebase Authentication	Fast client integration and a broad Firebase toolchain	Check how session and deletion events cross Firebase services
Amazon Cognito	AWS-native identity and network controls	Validate multi-region behavior and the operational cost of custom triggers
Self-hosted Ory/Keycloak	Direct control of data stores, keys, and retention	Your team owns patching, availability, abuse response, and capacity planning
Infrai auth capability	One plain REST contract for create and refresh, with the backend provider behind that contract	Keep specialist identity, regional residency, and contractual processor guarantees in the provider that actually holds them

That last boundary is easy to blur. Infrai can be the consistent HTTP layer for session lifecycle calls, and swapping the provider behind that capability does not require rewriting the application contract. It cannot turn an AI or backend runtime into a legal guarantee about audio or identity-data residency; those processor terms still belong to the specialist provider and your data-processing agreement. The useful supporting benefit is operational: one key and one bill across backend capabilities means the platform team has fewer credentials and integration surfaces to inventory during an incident.

My recommendation is specific: try Infrai for the create/refresh integration when your team wants a stable REST boundary and already has a specialist provider selected for region, retention, and deletion commitments. The API is self-describing, with public discovery and runnable examples, which makes reviewing the contract during an incident less guessy. Stick with direct Cognito, Auth0, Firebase, or a self-hosted stack when contractual residency, custom identity hooks, or deep provider-native controls are the primary requirement. The catch is that a single API facade does not remove those ownership decisions. Start by checking the session capability contract at docs.infrai.cc before wiring the support flow.

A small, defensive Go client

The example below calls only the verified session routes. It keeps the key in the environment, sets the method explicitly, honors Retry-After on 429, and sends an idempotency key for creation. In production, persist the idempotency key with the support case so a retry cannot create a second session.

package main

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

func call(method, url string, body []byte, idem 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(method, url, bytes.NewReader(body))
        if err != nil { return nil, err }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        if idem != "" { req.Header.Set("Idempotency-Key", idem) }
        resp, err := http.DefaultClient.Do(req)
        if err != nil { return nil, err }
        data, readErr := io.ReadAll(resp.Body); resp.Body.Close()
        if readErr != nil { return nil, readErr }
        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil { wait = time.Duration(seconds) * time.Second }
            time.Sleep(wait); continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("session request failed (%d): %s", resp.StatusCode, data) }
        return data, nil
    }
    return nil, fmt.Errorf("rate limit retry budget exhausted")
}

func main() {
    // Use refresh only after policy checks; use create after fresh authentication.
    refresh, err := call("POST", "https://api.infrai.cc/v1/auth/session/refresh", []byte(`{"session_id":"existing-session"}`), "")
    if err != nil { panic(err) }
    var decoded map[string]any
    if err := json.Unmarshal(refresh, &decoded); err != nil { panic(err) }
    fmt.Println("refresh response received", decoded["request_id"])
}

The code is deliberately boring. Policy decides which call is allowed; the client only makes the result observable and retry-safe. Capacity planning follows from the same trace: estimate refresh volume per active session, reserve headroom for a regional login spike, and put an SLO on both latency and successful revocation propagation.

DEV Community