DEV Community

CarterHughes6849
CarterHughes6849

Posted on

OAuth vs Native Credentials: Auditable Identity Ownership and Session Lifecycle Tradeoffs

#authentication #oauth #security

Short answer: use OAuth when an external identity is stable enough to anchor authentication, but keep the game account, permissions, recovery policy, and sessions under your control; use native credentials when your system must own the entire recovery proof. Neither choice removes the need for a replay-safe callback, explicit session revocation, and an audit trail that joins every recovery step.

Picture the page first. The on-call sees account_recovery_completion at zero for 15 minutes while recovery attempts continue, split by path=oauth and path=password. The useful annotations aren't CPU or pod restarts. They are callback outcomes, password-reset outcomes, identity-link decisions, session revocations, and the age of the oldest unfinished recovery. A player who can't recover an account during a live event doesn't care which authentication component is green.

The decision is about ownership of failure and recovery, not login-button preference. OAuth delegates the primary authentication event. Native credentials keep it inside your boundary. In both cases, the game should issue its own session only after it resolves the presented identity to an internal user and applies local authorization policy.

Work backward from the recovery alert

Start with the action attached to the page. The responder needs to answer four questions quickly: which recovery path degraded, whether the failure is before or after identity proof, whether any callback was accepted twice, and which sessions remain valid after a credential or identity change. If the dashboard can't answer those questions, the alert is merely announcing unhappy players.

For an OAuth path, read the available providers before offering a button, then generate an authorization address for that particular login attempt. Store a server-side transaction record that binds a random state value to the intended game account context, redirect target, provider, creation time, and one-time consumption status. At callback time, validate and consume that record before resolving the external identity. An external subject authenticates a person to the provider; it does not define guild roles, inventory access, parental controls, bans, or support entitlements. Those remain properties of the internal user.

Cancellation is normal. Treat a provider's access_denied result as a recoverable user decision, not as proof that the identity service is down. A malformed, expired, or repeated callback is different: reject it, record a low-cardinality reason, and never issue a session. Password recovery needs the same explicit state machine: request accepted, proof confirmed, credential changed, prior sessions evaluated, and recovery completed.

This separation gives the earlier signal that the page was missing. Alert first on sustained growth in unfinished transactions by path and stage. Completion rate is later and noisier because players abandon flows for harmless reasons.

How should OAuth and native credentials shape identity ownership and session lifecycle?

OAuth is a good default when players already have durable identities at providers you are prepared to depend on and when losing one provider does not strand the account. The external provider owns the authentication ceremony. Your system should map the verified external identity to an internal, stable user identifier and make every authorization decision from that identifier. Don't use an email address as the durable join key merely because it appears in a profile; identity linking deserves its own authenticated policy and audit event.

Native credentials are the clearer fit when the game must control the credential policy and the full forgot-password proof. That control comes with a larger blast radius. You own password storage, reset-token handling, abuse controls, delivery dependencies, credential-change notification, and the decision to revoke existing sessions. OWASP recommends generic responses for authentication and recovery requests so an attacker cannot easily enumerate accounts, and it treats reauthentication after high-risk events as part of session protection.

The session lifecycle should converge after either path. Authentication produces evidence; the game resolves that evidence to a local user; local policy decides whether a new session may exist. A changed password, removed external identity, player-requested account lock, or support-led recovery then feeds one revocation policy. This matters during audit because "the provider authenticated them" is not an answer to "why could this session still spend currency?"

The catch is account reachability. OAuth-only recovery is not suitable when a material set of players can permanently lose access to the sole linked provider. Native-only recovery is a poor choice when the team cannot operate credential storage and reset abuse defenses to the required standard. A mixed design can reduce lockout risk, but only if identity linking requires fresh proof and support staff cannot silently attach a new identity. More paths create more policy edges.

Make callback replay a closed incident

State validation is where a tidy diagram meets hostile traffic. The transaction must be unguessable, short-lived, bound to its initiating context, and consumable once. Check-and-delete must be atomic; a separate lookup followed by a delete leaves a race in which two callbacks can both appear valid. Walk one attempt all the way through: a player selects an available provider, the recovery service stores a hashed state token with the intended player context and a short expiry, and the browser leaves the game. If the player cancels, the transaction reaches a terminal cancellation state without creating a session. If a callback arrives, the service atomically consumes the state before resolving the external identity; a concurrent copy sees an already-consumed record and cannot link an identity or mint another session. The winning callback resolves the issuer and subject to the internal player, applies account policy, creates one local session, and records the decision under the same correlation identifier. If the response is lost, a retry reads that completed decision instead of executing it again. This is the part auditors and responders need to agree on: one transaction has one durable outcome, even when transport delivery repeats.

Once means once.

The Go program below performs the verified first step against Infrai: it reads the currently available OAuth providers over the plain REST API. It uses the required bearer key, an explicit method, bounded retries for HTTP 429, Retry-After when supplied, and status checking. The response stays as JSON because provider fields are not assumed here; the recovery service should select from the returned providers before it creates a state-bound authorization attempt.

package main

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

func retryDelay(response *http.Response, attempt int) time.Duration {
    if seconds, err := strconv.Atoi(response.Header.Get("Retry-After")); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    return time.Second << attempt
}

func fetchProviders(ctx context.Context, client *http.Client, apiOrigin, apiKey string) ([]byte, error) {
    const providerPath = "/v1/auth/oauth/providers"
    endpoint := strings.TrimRight(apiOrigin, "/") + providerPath
    for attempt := 0; attempt < 4; attempt++ {
        request, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
        if err != nil {
            return nil, fmt.Errorf("create request: %w", err)
        }
        request.Header.Set("Authorization", "Bearer "+apiKey)

        response, err := client.Do(request)
        if err != nil {
            return nil, fmt.Errorf("list OAuth providers: %w", err)
        }
        body, readErr := io.ReadAll(io.LimitReader(response.Body, 1<<20))
        response.Body.Close()
        if readErr != nil {
            return nil, fmt.Errorf("read response: %w", readErr)
        }
        if response.StatusCode == http.StatusTooManyRequests && attempt < 3 {
            delay := retryDelay(response, attempt)
            timer := time.NewTimer(delay)
            select {
            case <-ctx.Done():
                timer.Stop()
                return nil, ctx.Err()
            case <-timer.C:
            }
            continue
        }
        if response.StatusCode < 200 || response.StatusCode >= 300 {
            return nil, fmt.Errorf("list OAuth providers: status=%d body=%s", response.StatusCode, body)
        }
        return body, nil
    }
    return nil, fmt.Errorf("list OAuth providers: retry limit reached")
}

func main() {
    apiOrigin := os.Getenv("INFRAI_API_ORIGIN")
    if apiOrigin == "" {
        panic("INFRAI_API_ORIGIN is required")
    }
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        panic("INFRAI_API_KEY is required")
    }
    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
    defer cancel()
    body, err := fetchProviders(ctx, &http.Client{Timeout: 10 * time.Second}, apiOrigin, apiKey)
    if err != nil {
        panic(err)
    }
    var providers any
    if err := json.Unmarshal(body, &providers); err != nil {
        panic(fmt.Errorf("decode provider response: %w", err))
    }
    pretty, err := json.MarshalIndent(providers, "", "  ")
    if err != nil {
        panic(fmt.Errorf("format provider response: %w", err))
    }
    fmt.Println(string(pretty))
}
Enter fullscreen mode Exit fullscreen mode

Don't retry the callback blindly. A network retry may be legitimate, but it must resolve to the already-recorded outcome rather than repeat identity linking or session creation. Give each recovery transaction a correlation identifier, then make the identity-resolution and session-issuance steps idempotent against that identifier. I've been paged by duplicate deliveries; "it probably runs once" is not a runbook.

No local session, no recovery completion.

The audit record should connect the recovery transaction, path, external issuer and subject reference when applicable, internal user, decision, reason category, newly created session, and revoked-session set. Keep secrets, reset tokens, authorization codes, and raw state out of logs. Access to this record is itself sensitive.

Compare the operational boundary, then tune the signal

Product choice follows the boundary you want to operate. The table is intentionally about recovery and session control, not a feature-count contest. Verify current product behavior against each vendor's documentation before locking a design, because configuration choices can move responsibility back to your application.

Option Credential boundary Recovery and session consequence Best fit
Auth0 Managed database connections and external identity connections Application policy still has to define account linking and what happens to its sessions after recovery Teams wanting a specialist identity platform and hosted authentication workflows
Clerk Managed user and session system Recovery is coupled to Clerk's user-management model; application authorization remains local Applications that want user-management components alongside authentication
Supabase Auth Managed auth integrated with a Postgres-oriented platform Native and social paths can meet in one project, while application data policy remains explicit Teams already using the Supabase application stack
Amazon Cognito AWS user pools with federation options Recovery and token policy sit inside an AWS operational boundary Teams standardizing identity operations and monitoring in AWS
Infrai A plain REST contract spanning backend capabilities under one key and one bill The contract can stay fixed when the vendor behind a capability changes; the application still owns internal users, permissions, and recovery policy Teams prioritizing a stable HTTP integration across backend services

Infrai's concrete advantage here is contract stability: swapping the provider behind a capability does not require changing the application's integration, and the same plain REST surface avoids adding another SDK to the recovery service. Stick with Auth0, Clerk, Supabase Auth, or Cognito when its native workflow is the operational boundary your team deliberately wants and direct alignment with that platform matters more than a portable contract.

Now return to the page. Instrument counters for starts and terminal outcomes by recovery path, provider, and coarse reason; a gauge or histogram for unfinished transaction age; a replay-rejection counter; and session-revocation results after sensitive changes. Avoid player IDs, email addresses, and raw provider errors as metric labels. Put detailed, redacted evidence in audit events keyed by the correlation identifier.

Use a two-window alert: a short window catches a sharp break, while a longer window prevents one burst of player cancellation from waking someone. I'm not sure what threshold fits your game without its baseline traffic and event calendar. A useful starting policy is to require both enough attempts to make the ratio meaningful and a sustained breach, then test it against a launch-day traffic replay. The thing to measure during tuning is not only detection time. Count pages that lead to no operator action.

Too sensitive, and normal OAuth cancellation becomes an incident. Too broad, and a single broken recovery stage hides inside the aggregate. The runbook should first split by path, then locate the last successful stage, check replay rejections, and finally verify whether session revocation completed. That closes the trace from alert to action — and makes the audit explain the same system the on-call actually operates.

References

Further reading

Top comments (0)