View as Markdown

Authentication

Nakama requires every client to authenticate before accessing server features. Client applications connect using a server key that identifies and authorizes the application. Individual users then authenticate using one of the supported methods to obtain a session token.

The default server key is defaultkey. Change this to a unique value before deploying to production and embed it in your client code.

Each user account can have multiple authentication methods linked to it, allowing the same user to sign in across different devices or platforms.

How accounts and identifiers relate #

A Nakama account is one server-side record with one or more identifiers linked to it. An account can have multiple device IDs, but only one social ID per provider: one Apple ID, one Game Center player, one Google account, one Facebook profile, and so on. Any one of these identifiers is enough to sign the player into the same account, from any device.

Nakama Console authentication panel showing one account with three device IDs and a linked Game Center ID
One Nakama account: several device IDs, one slot per social provider

With a social provider, you obtain an OAuth or access token from the service and pass it to Nakama. Nakama verifies the token with the provider, fetches the player’s profile, and resolves it to the account that owns that social ID, creating one on first sign-in. More at Social providers .

Two operations manage the identifiers on an account:

  • Authenticate signs the player in. Nakama finds the account that owns the identifier you pass, or creates one if none exists, and returns a session .
  • Link attaches an additional identifier to the account the player is already signed into. It returns nothing and leaves the current session unchanged.
AspectAuthenticateLink
What it doesFinds the account that owns this identifier, or creates one if none existsAttaches an additional identifier to the account you’re already signed into
ReturnsA session (auth token and refresh token)Nothing. The current session is unchanged

Linking has two constraints worth knowing up front: linking an identifier that already belongs to another account returns a 409, and unlinking an account’s only remaining identifier returns a 403. Both are covered in Link or unlink .

Ways to associate an identifier #

Because any linked identifier resolves to the same account, you can combine authenticate and link into more than one valid pathway, depending on which identifier the player has first:

  • Device ID first, social ID linked later: authenticate with a device ID, then link a social ID once the player signs in with one, from a settings menu or an in-game prompt.
  • Social ID first, device ID linked after: authenticate with a social provider such as Game Center or Google Play Games, then link the device ID so the same fallback resolves to this account on future launches.

The silent social sign-in guide walks through the social-ID-first pathway end to end.

Authentication methods #

Nakama supports a range of authentication methods: device ID, email, several social providers, and custom identifiers. Each method produces a session token that gives the client access to the server.

By default, authenticating with an identifier that doesn’t yet exist in the system will automatically create a new user account. To authenticate without creating an account, set create to false.

For full SDK examples, see the client library guides .

Device #

A device identifier can be used as a way to unobtrusively register a user with the server. This offers a frictionless user experience but can be unreliable because device identifiers can sometimes change in device updates.

Don’t use OS-level hardware identifiers (such as OS.get_unique_id() in Godot) as these are accessible to other apps on the device and could let them authenticate as your users. Instead, generate a secure random UUID on first launch and store it in your app’s private local storage. The examples below demonstrate this approach.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

A device identifier must contain alphanumeric characters with dashes and be between 10 and 128 bytes.

In games it is often a better option to use Google or Game Center to unobtrusively register the user.

Email #

Users can be registered with an email and password. The password is hashed before it’s stored in the database server and cannot be read or “recovered” by administrators. This protects a user’s privacy.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

An email address must be valid as defined by RFC-5322 and passwords must be at least 8 characters.

Once an account has been created with email + password (and optionally a username), you may also authenticate with username + password using the same email authentication endpoint (or SDK function). In this case, pass the email argument as an empty string ("").

Console #

Nakama supports console authentication for all major platforms, including Nintendo Switch, Xbox One and Series X|S, and PlayStation 4/5.

Requesting Access
Console authentication is only available to developers verified by the respective console platform providers (Sony, Microsoft, Nintendo). To request access, please contact us .

The console authentication flow is similar to the device authentication flow, but requires a console identifier and a console user identifier.

Note that the examples below are only meant to be illustrative. Complete documentation can only be provided following your verification by the console platform provider(s).

Social providers #

The server supports a lot of different social services with register and login. With each provider the user account will be fetched from the social service and used to setup the user. In some cases a user’s friends will also be fetched and added to their friends list.

To register or login as a user with any of the providers an OAuth or access token must be obtained from that social service.

When a social login fails, the client receives a generic message such as Could not authenticate Google profile., while the provider’s specific reason (for example, an invalid or expired token) is written to the server log. For how to debug these, see Social authentication errors .

Apple #

Follow the Apple Developer documentation for integrating Sign in with Apple in your applications.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

{

Game Center #

Game Center provides built-in authentication on Apple devices without requiring user interaction. To authenticate, pass the player credentials provided by Apple’s GameKit framework.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

Facebook #

With Facebook you’ll need to add the Facebook SDK to your project which can be downloaded online. Follow their guides on how to integrate the code. With a mobile project you’ll also need to complete instructions on how to configure iOS and Android.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

When authenticating via Facebook, the following profile fields are fetched and stored in the user account:

  • ID
  • Name
  • Email
  • Photo

Additionally, you can optionally import Facebook friends into Nakama’s friend graph when authenticating. To do this, set import to true.

Facebook Access Token Validator
The Facebook SDK supports various types of authentication tokens, Nakama Authentication supports User Tokens (opaque) and Limited Login Tokens (OpenID Connect JWT). You should be aware that friend import only works with the former tokens, as Nakama needs to access the FB Graph API. Friend data is available only for users that have authorized your App on FB (both the authenticating user and their friends). In the case that Access Tokens are used, this Access Token Validator may be useful to debug any issues you encounter while integrating with the Nakama Authentication APIs.

Facebook Instant #

Ensure that you’ve configured your FB Instant App secret for Nakama and initialized the Facebook Instant Games SDK using FBInstant.initializeAsync().

Google #

Nakama supports two Google authentication flows through the same endpoint (/v2/account/authenticate/google) and SDK method (AuthenticateGoogleAsync). The credential type you pass determines which flow is used:

  • Google Sign-In: Pass the ID token (JWT) from the Google Sign-In SDK .
  • Play Game Services (PGS) v2: Pass the server-side auth code from the Play Games SDK. Requires additional Nakama server configuration (see below)

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

Google Sign-In #

Pass the ID token returned by the Google Sign-In SDK as the token parameter:

Play Game Services (PGS) #

PGS v1 is deprecated; use PGS v2. PGS v2 uses server-side access: the client obtains a server-side auth code from the Play Games SDK, which Nakama exchanges for credentials on the server. Pass this server-side auth code as the token parameter. The SDK call is otherwise identical to Google Sign-In above.

Because the exchange happens server-side, Nakama must be configured with credentials that authorize it to call the Play Games API. Obtain the credentials JSON from your Play Games server-side setup — these must include read scopes for the Players:get endpoint . These credentials are separate from any service account used for IAP validation .

Nakama configuration required
Set google_auth.credentials_json in your Nakama server configuration before using PGS v2 authentication.

Steam #

Steam requires you to configure the server before you can register a user. Have a look at the configuration section for what settings you need for the server.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

You can optionally import Steam friends into Nakama’s friend graph when authenticating. To do this, set import to true.

Custom #

A custom identifier can be used in a similar way to a device identifier to login or register a user. This option should be used if you have an external or custom user identity service which you want to use. For example EA’s Origin service handles accounts which have their own user IDs.

A custom identifier must contain alphanumeric characters with dashes and be between 6 and 128 bytes.

You can choose a custom username when creating the account. To do this, set username to a custom name. If you want to only authenticate without implicitly creating a user account, set create to false.

Session #

When an authentication call succeeds, the server responds with a session object. The session object contains at least the following:

  • The user ID
  • The username
  • A set of variables cached in the token
  • The creation time
  • The expiration time

Once the client obtains the session object, you can utilize Nakama’s real-time features such as multiplayer , notifications and status updates , passing stream data or real-time chat .

For details on token lifetimes, session refresh, and SDK auto-refresh support, see Sessions .

You can link one or more other login option to the current user. This makes it easy to support multiple logins with each user and easily identify a user across devices.

You can only link device IDs, custom IDs, and social provider IDs that are not already in use with another user account. Linking an identifier that already belongs to another account returns an error with code 409. For how to resolve such account conflict scenarios, see this section in the silent social sign-in guide.

If using Hiro, call RefreshAsync() after linking to sync the cached account. If the social account belongs to a different Nakama user, linking will fail. See Replace an existing session for how to handle that case.

You can unlink any linked login options for the current user.

Nakama won’t remove an account’s last identifier. If you unlink the only identifier left on an account, the call returns a 403. Link another identifier first, then unlink.

You can link or unlink many different account options.

| Link | Description |

AppleAn Apple account.
CustomA custom identifier from another identity service.
DeviceA unique identifier for a device which belongs to the user.
EmailAn email and password set by the user.
FacebookA Facebook social account. You can optionally import Facebook Friends upon linking.
Game CenterAn account from Apple’s Game Center service.
GoogleA Google account.
SteamAn account from the Steam network.