View as Markdown

Sessions

Every request your client makes to Nakama must be authorized. A session is the period of authenticated access that makes this possible: when a player authenticates, Nakama issues a signed JSON Web Token (JWT) that your client presents with each subsequent request. Because the token is cryptographically signed, Nakama validates it in memory without a database lookup on every call.

Sessions are time-limited by design. Nakama issues two tokens at authentication: a short-lived session token for authorizing requests, and a longer-lived refresh token for obtaining a new session token without requiring the player to sign in again.

TokenDefaultConfig key
Session token60 secondssession.token_expiry_sec
Refresh token3,600 seconds (1 hour)session.refresh_token_expiry_sec

Set both values in your server configuration. The session token lifetime controls how often your client refreshes. The 60-second default is intentionally short, and most production deployments set it to around 2 to 3 times the game’s average play session.

The refresh token lifetime determines how long a player stays logged in between sessions without re-authenticating. A typical range is 24 hours to 30 days.

Authentication vs. authorization
Authentication is proving who you are (logging in with your credentials). Authorization is proving you’re allowed to make a request (what happens on every subsequent call when your client presents its session token). For a deeper explanation, see Authentication vs. authorization.

Session details #

Access a user’s ID, name, and whether or not their session has expired:

Session refresh #

When the session token expires, call the session refresh endpoint with the refresh token to receive a new session token and refresh token pair. If the refresh token has also expired, or the session has been revoked via logout, the player must re-authenticate.

You can optionally provide new session variable values when refreshing a session. These new values will replace any session variables currently stored in the session object.

How auto-refresh works #

Most Nakama client SDKs refresh sessions automatically. Before each API call, the client checks whether the session token expires within the next five minutes and calls the refresh endpoint transparently. To confirm whether your SDK supports this, check its client library documentation for an autoRefreshSession parameter on the Client constructor. If present, auto-refresh is enabled by default.

The following shows the pattern for .NET and Unity:

1
2
3
4
5
6
// Auto-refresh is enabled by default.
var client = new Client("http", "127.0.0.1", 7350, "defaultkey");

// To opt out, pass false as the last argument.
var client = new Client("http", "127.0.0.1", 7350, "defaultkey",
    UnityWebRequestAdapter.Instance, autoRefreshSession: false);

When a session refreshes, the SDK fires a ReceivedSessionUpdated event with the updated session. Subscribe to this event and save the tokens to persistent storage. You’ll need the refresh token on the next app start.

1
2
3
4
client.ReceivedSessionUpdated += updatedSession => {
    PlayerPrefs.SetString("nakama.authToken", updatedSession.AuthToken);
    PlayerPrefs.SetString("nakama.refreshToken", updatedSession.RefreshToken);
};

On app start, restore the session from storage. If the auth token has expired, use the refresh token to get a new one silently rather than forcing the player to log in again. Only fall back to full authentication if the refresh token has also expired.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
var authToken = PlayerPrefs.GetString("nakama.authToken");
var refreshToken = PlayerPrefs.GetString("nakama.refreshToken");

if (!string.IsNullOrEmpty(refreshToken))
{
    var session = Session.Restore(authToken, refreshToken);
    if (session.IsExpired)
    {
        session = await client.SessionRefreshAsync(session);
        PlayerPrefs.SetString("nakama.authToken", session.AuthToken);
        PlayerPrefs.SetString("nakama.refreshToken", session.RefreshToken);
    }
}
else
{
    // No stored session — authenticate from scratch.
}

If your SDK doesn’t support auto-refresh, call the session refresh endpoint manually before the session token expires.

Session logout #

It is good security practice to enable users to logout of an active session. This can be used to prevent unauthorized access by another person when using a shared device, for example.

Logging out of a user’s session invalidates their authentication and refresh tokens, but does not disconnect their open socket connections. This can be accomplished via the server-side sessionDisconnect function. See the corresponding function reference.

Session variables #

Session variables allow clients and server-side code to embed additional key/value pairs into the session token generated by the game backend. This enables the session token to act as an edge cache, with the information available as long as the session remains active.

These can be used to implement different features and tools, such as analytics, referral bonuses, or rewards programs.

You can optionally provide new session variable values when refreshing a session. These new values will replace any session variables currently stored in the session object.

Setting with client #

To set the variables in the client’s request for authentication use:

This example shows setting session variables with Email Authentication, but this feature is available for all of the other authentication options and in all client libraries.

Setting with server #

Session variables may be set by the server, but only in the before authentication hooks.

Accessing with server #

Once set, session variables become read-only and may be accessed in any server hook. The only way to change or delete a session variable is through forcing the client to authenticate again.

Related Pages