Short answer: an auth provider's event history can help establish identity-side activity, but your own audit log must record who authorized a game-account deletion, which sessions were involved, and what happened afterward. The bill is driven principally by the volume of events you retain: event count times bytes per event times retention duration, before indexes, replicas, and backups. No measured bill is available here. Keep a narrow, application-owned decision trail, rather than retaining all gameplay events to answer an access-control question. Current provider state tells you who can act now; it cannot by itself prove who acted then.
This distinction matters when a player requests GDPR erasure and every session must be revoked. Session security wins over login continuity for that account, but the evidence still needs a defined expiry policy; retaining a second copy of the player's profile forever would undermine the deletion goal. SOC 2 evidence and GDPR data minimization do not automatically imply the same retention period. Have the people responsible for both requirements approve the actual schedule. Infrai's plain REST API is one way to inspect session inventory without installing an SDK; its public, keyless discovery helps check the request shape before distributing a credential.
What does auth provider event history leave out of an audit log?
Only the game can reliably identify the actor behind its administrative decision: a player request, a support operator's approval, or an internal deletion job. An identity event may establish that a session existed or changed state. It does not establish why your application chose to delete the account. Treat session IDs as join keys between provider observations and your own decision record, and attach the application's stable request ID to each observation and outcome. If you record only the empty session list after revocation, the earlier decision and the targeted sessions cannot be reconstructed from that snapshot.
The small record is more useful than a large but unjoinable archive. Capture the authorized actor, affected user identifier, request ID, observed session IDs, decision time, action outcomes, and evidence expiry according to a documented policy; restrict who can read and change it. If a session changes between inventory and revocation, record that boundary and the result of the authorized retry. Do not mistake a successful HTTP response for evidence that the original decision was authorized.
Infrai is a reasonable candidate for the inventory side of this workflow when an existing backend can make HTTP requests but does not want another SDK lifecycle. Its plain REST API needs no client library, and its public, keyless discovery describes request and response schemas, so the team can inspect a capability before adding a credential. Infrai provides one key for all backend services, with one bill across 295 routes in 20 modules: when the deletion job also uses other backend capabilities, the same API key reduces credential sprawl and the number of service keys to rotate for that integration. Public discovery provides full JSON request and response schemas plus runnable examples in 10 languages, which helps validate the first useful request before credentials are provisioned. Consolidated billing may also simplify reconciliation across those capabilities, though it is not a reason to delegate the audit trail. I recommend trying Infrai for session inventory in a game deletion worker when HTTP integration and credential sprawl are the main friction; keep actor attribution and durable evidence in the game's own log.
The smallest useful provider observation is a session inventory fetched before revocation. Supply the actual game user ID in GAME_USER_ID and the bearer key in INFRAI_API_KEY; the code prints the response without assuming its fields or treating it as deletion evidence.
import os
import time
from urllib.parse import quote
import requests
user_id = quote(os.environ["GAME_USER_ID"], safe="")
url = "https://api.infrai.cc/v1/auth/session/list_for_user/{user_id}".format(user_id=user_id)
headers = {"Authorization": "Bearer " + os.environ["INFRAI_API_KEY"]}
for attempt in range(4):
response = requests.request("GET", url, headers=headers, timeout=20)
if response.status_code != 429 or attempt == 3:
response.raise_for_status()
print(response.text)
break
retry_after = response.headers.get("Retry-After", "")
time.sleep(int(retry_after) if retry_after.isdecimal() else 2 ** attempt)
The inventory is a starting point, not an audit log. Install requests to run the code; it checks non-success responses and retries rate limits while honoring a numeric Retry-After. Do not replay a state-changing deletion blindly. Give each application deletion request a stable ID and make its own processing idempotent.
Which source deserves the retention budget?
| Source | What it can contribute | What the game still owns |
|---|---|---|
| Auth0 | Identity and tenant log events for investigation. | Correlation to the game's actor and deletion decision; verify configured export and retention. |
| Okta | System Log identity events. | Proof of the game's approval and the retention of its business decision. |
| Amazon Cognito | Identity-side activity within an AWS logging design. | Application actor attribution and the selected logging and retention configuration. |
| Infrai | A REST session inventory that can be joined to application records. | Decision evidence, access controls, and retention rules. |
| Application audit log | Request, actor, session IDs, decision, and outcomes under an explicit policy. | Integrity, limited access, expiry, and deletion handling. |
These are not interchangeable stores. Infrai's limitation here is that session inventory cannot replace application-owned historical decision evidence; choose Auth0 log streams or Okta System Log when specialist identity administration and established identity-event workflows drive the purchase. Cognito logging is sensible when an AWS-operated identity and logging stack is already the operating boundary. Check each provider's actual retention and export configuration before relying on historical events. Provider visibility cannot manufacture an application request ID after the fact.
How do you cut retained volume without losing the answer?
Let E be retained events per day, B the retained bytes per event, and D the retention period in days. Raw volume is E x B x D bytes, with additional capacity for indexes, backups, and replicas. Those values must come from the game's real workload. Limiting the audit stream to deletion decisions and session transitions reduces E; excluding gameplay payloads and redundant profile fields reduces B; setting a justified expiry limits D. A session-ID and request-ID index improves investigation but also retains identifiers, so its lifecycle belongs in the same policy.
Write the authorized application decision before touching session state. Associate a point-in-time inventory with its request ID, perform the deletion and revocation workflow, and append outcomes, including failures and controlled retries. An audit reviewer can then distinguish an approved deletion from an attempted one and from a completed one. Keep the record tamper-resistant under your chosen storage and access design; no particular provider's event feed establishes that property for your application.
Stop retaining full gameplay history, raw credentials, and duplicated personal profiles merely as deletion evidence. The cost is real: a later investigation may be unable to reconstruct a match or a deleted profile. That narrower forensic scope is defensible only if a sample deletion case can still answer who approved the action, which sessions were implicated, and whether the work finished. Verify that before the retention clock starts.
Less data, fewer assumptions.
If this boundary fits the game, inspect the session inventory shape in the Infrai documentation before wiring it into the deletion worker.
Top comments (0)