01 — session & identity
Player session
The hub launches your game in an iframe and hands you the player's identity in the URL. Your Unity client forwards it; your backend verifies it. That's the whole auth story.
The launch URL
https://<your-game>.domin8.fun/?cabinet=true&token=sol&session=<JWT>
| Param | Meaning |
|---|---|
token | The currency the player bets in — sol or eth. Frozen for the session; pass it on every money call. |
session | A JWT identifying the player. It rides in the URL because a cross-origin iframe can't read the hub's cookie. |
freeplay=true&balance=… | Free-play mode — see below. |
Client side (Unity)
Read session from the launch URL at boot and attach it to every request to your backend:
Authorization: Bearer <JWT>
Server side (your backend)
Verify the JWT on every request. It is signed with HS256:
| Check | Value |
|---|---|
| Algorithm | HS256 |
| Secret | env JWT_SIGNING_SECRET — injected at deploy time |
| Issuer | domin8 |
| Audience | domin8-hub |
| sub claim | the platform user_id (e.g. tg:123456789) — use this exact string in every bank and RNG call |
Never trust a client-sent user id
The
user_id must always come out of the verified JWT, never from the request body. Reject any request with a missing or invalid token.Free play
With freeplay=true there is no session and no money: don't call the bank at all. Keep a local fake balance in the client (starting at the balance param) and run the same spin visuals. When the player wants the real thing, send { type: "domin8:play-for-real" } to the parent frame and the hub takes over.