GS2-Identifier

Credential management feature

GS2-Identifier is a service that manages credentials for accessing the GS2 management console and GS2 APIs.

It issues and manages users associated with a GS2 owner account, the permissions (security policies) granted to each user, and the client ID / client secret actually used to call APIs.

GS2-Identifier is a service that is not intended to be called directly from game clients; it is used for operator-side setup, deployment automation, and CI/CD pipelines.

IAM-like design

GS2-Identifier provides concepts equivalent to IAM (Identity and Access Management) in cloud services.

The main elements are as follows.

User: An individual operating entity created under a GS2 owner account
Security Policy: A policy document that describes the resources and actions that may be operated
Attaching a Security Policy: Associates a security policy with a user to grant permissions
Client ID / Client Secret: API credentials issued per user

graph TD
  Owner["GS2 Owner"] --> User["User"]
  User -->|Attach| Policy["Security Policy"]
  User -->|Issue| Credential["Client ID<br/>Client Secret"]
  Credential -->|Authenticate| API["GS2 API"]
  Policy -->|Authorize| API

Security Policy

A security policy is a permission definition written in JSON format. By describing the resource GRNs to allow and the actions to allow (operation identifiers such as Gs2Account:CreateAccount), it expresses what operations are permitted for users to whom the policy is attached.

It is recommended to design appropriate policies for each development and operational phase, and to grant least privilege per user.

Client ID / Client Secret

The client ID and client secret issued to a user are used as authentication information when calling GS2 APIs. Multiple credentials can be issued per user, and you can use them appropriately for different purposes or devices.

The client secret can only be obtained at the time of issuance; after that, it cannot be retrieved from GS2. If it is leaked, delete the credential and reissue it.

Phased permission grants in conjunction with GS2-Version

In GS2-Identifier, you can require a credential associated with a user to obtain a Project Token issued by GS2-Version as a “guard”.

Specifically, you can give only weak permissions (“enough to perform login and version check”) to the client ID / client secret embedded in the application, and design the system so that strongly-privileged credentials issued after a successful version check are used to access the actual game.

graph TD
  App["Application-embedded<br/>credential<br/>(Least privilege)"] -->|Version check| Version["GS2-Version"]
  Version -->|Issue Project Token| App
  App -->|Authenticate with Project Token| Strong["Strongly-privileged<br/>credential"]
  Strong -->|Call game APIs| API["GS2 API"]

This flow prevents clients running on old application binaries or on asset versions that are no longer supported from continuing to access the game APIs. For details, see the GS2-Version documentation.

Two-Factor Authentication

You can enable two-factor authentication for users who log in to the GS2 management console. GS2-Identifier manages the configuration information for two-factor authentication.

Transaction Actions

GS2-Identifier does not provide transaction actions.

Master Data Management

GS2-Identifier does not have master data registration. Security policies, users, and credentials are managed directly via the management console, GS2-Deploy, or APIs.

Example Implementation

GS2-Identifier is a microservice centered on management / server-side APIs. No dedicated Domain class is provided in the game engine SDKs (Unity / Unreal Engine).

Management operations for users, security policies, and credentials are expected to be executed from operator-side setup, deployment automation, or CI/CD pipelines, so we recommend operating via one of the following means.

GS2 management console (manage users, policies, and credentials via GUI)
Define users, policies, and credentials in GS2-Deploy templates and apply them from CI
Call management APIs from operator tools using general-purpose SDKs for various languages (C# / Go / Python / TypeScript / PHP / Java)
GS2 CLI

For details on each SDK, see the corresponding reference page.

Obtaining a Project Token

As an exception, user login (issuing a Project Token) is sometimes performed on the application side. By calling the Login API with the embedded client ID / client secret and using the obtained Project Token as authentication information for GS2 APIs, you can call APIs within the scope of the security policies associated with the user.

The login API should be called using general-purpose SDKs for various languages (C# / Go / Python / TypeScript / PHP / Java) rather than via the game engine SDK Domain. When combined with GS2-Version, you can achieve phased permission grants by issuing the Project Token after the version check.

More practical information

Separation of permissions per operational phase

The kinds and strength of permissions required differ between the development and production phases. Because GS2-Identifier can attach a different security policy to each user, the following account design is possible.

Developer user: Read/write only on resources in the development environment
Operator user: Read and limited write on resources in the production environment
CI user: Permissions necessary to run GS2-Deploy
Game client-embedded user: Can only perform login and version check

By issuing dedicated credentials per operating entity and operating under the principle of least privilege, you can limit the impact if a credential is ever leaked.

Credential rotation

To maintain security, we recommend periodically rotating client IDs and client secrets. By following the procedure of issuing a new credential and then deleting the old one, you can switch over without downtime.