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:- The token is at most 4,096 characters and has three parts.
- The header’s
algisHS256and itstypisJWT. - The game server has a
SESSION_SECRETof at least 32 characters. - The signature matches.
submatches its pattern.issequals the issuer in your settings, and an issuer is set.audisog-rgs-v1.tenantequals your casino ID.currency, or your only currency when the claim is absent, is one your casino serves.expis an integer, in the future and at most an hour ahead.- If
cnfis present, it is an Ed25519 JWK whosexmatches 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
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 asAuthorization: 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.