Skip to main content
InternalMarkdown

ADR 0003. Authenticate at a Boundary Point, Not Per-Action

Status​

Superseded by ADR 0015 (PlayerPal is off the game path) and ADR 0016 (BFF cookies, popup linking, machine OAuth).

The original "signed JWT at operator login for an embedded widget" model is not current. Identity is still resolved at a control-plane boundary, not per gameplay action. That part stands, but the token and transport design does not.

Context​

Gameplay actions can be extremely high frequency. Requiring PlayerPal identity resolution (a DB lookup) on every action would put PlayerPal in the critical path of gameplay, adding latency, cost, and a failure coupling that shouldn't exist.

Decision​

Resolve/authenticate identity once, at a boundary point (operator login), and issue a short-lived signed JWT carrying scoped claims. Both the operator/app and the embedded PlayerPal widget can read it without a fresh DB hit. The token stays small, avoids sensitive PII, and excludes fast-changing state (e.g. live balance). That is fetched separately via GET /v1/me/loyalty.

Consequences​

  • No DB lookup per gameplay action; gameplay stays fast and decoupled from PlayerPal's availability.
  • Token content is a trade-off: richer claims reduce round-trips but increase staleness risk and token size. Claim set is not yet finalized.
  • Revocation is harder with self-contained JWTs than with server-side sessions. Token lifetime needs to be short enough that this is acceptable (still an open decision).