CONCEPT Cited by 1 source
Dual-token authentication¶
Definition¶
Dual-token authentication is a session-management pattern where two independent token systems — typically a managed identity provider (issuing identity tokens) and an application server (issuing session tokens) — operate in parallel with distinct lifecycles, each validated independently on every request. A one-time server-side bridge translates a verified identity token into an application session token; after the bridge, neither system depends on the other at runtime.
Why two tokens¶
A single-token model forces the application server to either (a) call back to the identity provider on every request (latency, coupling) or (b) fully trust the identity provider's token format (locks the application to the provider's schema and lifecycle). Dual-token decouples:
- The identity provider owns authentication strength, credential storage, MFA, and account recovery — issuing a short-lived JWT (typically 1 hour).
- The application server owns session semantics, presence, permissions scoped to the app domain — issuing its own session token (typically 2–8 hours).
The bridge is a single server-side validation step: verify the identity JWT cryptographically, extract the subject claim, and issue an application session token bound to that subject. The identity JWT is never seen again by the application after this point.
Canonical instance¶
The AWS Architecture Blog's Nakama + Amazon Cognito reference architecture (2026-06-29) is the wiki's canonical production reference:
- Cognito issues a JWT (
sub= player UUID, 1-hour expiry, RS256 signed). - A Go runtime hook on the game server validates the JWT (5-step: format →
algorithm → signature → expiry → issuer/audience), extracts
sub, and overwrites the Nakama user ID. - Nakama issues its own session token (2-hour expiry) for all subsequent game API calls and WebSocket connections.
- Each token validated independently: Cognito JWT only at bridge time; Nakama session token on every subsequent request.
(Source: sources/2026-06-29-aws-dual-token-authentication-for-nakama-game-servers)
Trade-offs¶
| Dimension | Dual-token | Single-token (identity provider only) |
|---|---|---|
| Runtime coupling | None after bridge | Every request depends on provider |
| Session semantics | Application-native (presence, permissions) | Must encode in IdP token or call out |
| Token lifecycle | Independent tuning (short identity, longer session) | Single lifecycle for all concerns |
| Complexity | Two validation paths, bridge logic | Simpler flow, tighter coupling |
| Revocation | Must revoke both (or use single-socket enforcement) | Single revocation point |
Seen in¶
- sources/2026-06-29-aws-dual-token-authentication-for-nakama-game-servers — Cognito + Nakama on AWS
- Generalises to any game server (Colyseus, Photon, custom WebSocket backends) or real-time application that manages its own session state independently of the identity provider.