Session Management for Games (Keep Players Signed In, Safely)

Session management is the invisible work that turns "signed in" into "stays signed in." Players expect to authenticate once and never think about it again — while you still need the power to end a session when an account is stolen, a device is lost, or a cheater needs banning. Those two goals pull against each other, and managing sessions well is how you satisfy both.

What a session actually is

A session is the ongoing state of "this player is authenticated," built out of tokens. When a player signs in, you get a short-lived access token and a long-lived refresh token. The access token authorizes calls; the refresh token exists to renew the access token without a login screen. The session is the lifespan those tokens define together — and managing it well comes down to four questions.

1. Staying signed in across launches

Nobody wants to log in every time the game boots. The mechanism is silent resume: on launch, use the stored refresh token to get a new access token instead of showing a login screen. That depends entirely on having stored the refresh token securely in the first place — see storing auth tokens in Unity, because a session is only as safe as where its refresh token lives.

With Oathwall's Unity SDK, this is SilentLogin(): it resumes a saved session automatically and only falls back to a login prompt when there's nothing to resume or the session has been revoked.

2. Renewing without interrupting play

Access tokens expire fast on purpose — about an hour with Oathwall. Mid-session, that expiry has to be invisible: when a call would fail with a 401, the refresh token quietly fetches a new access token and play continues.

The detail that bites hand-rolled code is rotation. Every refresh returns a new refresh token and retires the old one, so you must store the new one each time — reuse the retired token and the next renewal fails. Oathwall's refresh sessions last 30 days on a rolling basis, extended each time you refresh, and the kit handles the rotation for you.

3. Multiple devices

A player on their phone and their desktop has two independent sessions, each with its own refresh token. That's what lets you end one without disturbing the other. Oathwall's dashboard shows active sessions across devices and lets you revoke any single one, while logout ends just the current session — the phone stays signed in when you sign the desktop out.

4. Ending a session on demand

This is the half that pure client-side "just keep the token" approaches get wrong. You need server-authoritative revocation — the ability to kill a session from your side, right now, for a stolen account, a lost device, or a banned cheater. If a session is only valid until its access token expires, a banned player keeps playing for the rest of that hour.

Oathwall checks the player's status on every request, so a ban or deactivation takes effect immediately rather than waiting out the token. Revoking a session invalidates its refresh token, so it can't mint new access tokens either. Between short access tokens and instant revocation, the longest a revoked session can linger is the access token's remaining minutes — and a ban closes even that.

Letting the kit run the session

Put together, good session management is silent resume, invisible refresh with rotation, per-device control, and instant revocation. Oathwall's SSO Login Kit runs the client half for you:

using PixitGames.SSOLoginKit;

public class SessionBoot : SsoClientBase
{
    // Resume silently on launch; refresh and rotation
    // happen under the hood while the player plays.
    void Start() => SilentLogin();

    protected override void OnLoginSuccess(LoginResult user)
        => Debug.Log($"Session active for {user.name}");
}

For the tokens that make a session work, read access tokens vs refresh tokens; for keeping them safe, storing auth tokens in Unity. The Unity authentication guide shows the full picture from first login to a long-lived, revocable session.