Skip to main content
A session token is a compact JWT signed with HMAC-SHA256. Session tokens shows how to sign one; this page is the exact contract.

Format

A token decoded, for a player of Lucky Star betting in US dollars:
Header
Claims

Claims

Other claims, such as iat or jti, are ignored.

The checks, in order

The game server refuses the token at the first check that fails:
  1. The token is at most 4,096 characters and has three parts.
  2. The header’s alg is HS256 and its typ is JWT.
  3. The game server has a SESSION_SECRET of at least 32 characters.
  4. The signature matches.
  5. sub matches its pattern.
  6. iss equals the issuer in your settings, and an issuer is set.
  7. aud is og-rgs-v1.
  8. tenant equals your casino ID.
  9. currency, or your only currency when the claim is absent, is one your casino serves.
  10. exp is an integer, in the future and at most an hour ahead.
  11. If cnf is present, it is an Ed25519 JWK whose x matches the canonical 43-character form.

When a check fails

Every failed check answers the same way, so a token reveals nothing about which rule it broke:
HTTP 401
A token whose header or claims are not valid base64url JSON fails earlier, with 409 and {"error": "request_failed"}. Debug a refused token by decoding it and comparing each claim with the table above, starting with iss, tenant, currency and exp. Troubleshooting walks through the usual causes.

How the element sends it

The element sends the token as Authorization: Bearer <token> on HTTP requests, and as the WebSocket subprotocol auth.<token>, next to og.v1, when it opens the game connection. The game server never reads a token from a URL. When a token expires during a connection, the game server closes the connection with code 4001, Session expired. The element renews tokens before they expire, so players only see this when your session endpoint stops answering.