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.

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.

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.

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.

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 which are not already in-use with another user account.

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

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.