Glossary

access key

A credential used to authenticate server-to-server API requests on behalf of an application. Stored securely on the server side and never exposed to clients. Each application can have up to two active access keys at a time, see API Access Key for Application.

access token

A short-lived OAuth 2.0 token with a 1-hour lifetime, returned after successful authorization. Used to access protected resources and request user profile data. Can be exchanged for a user JSON Web Token (JWT), see OAuth 2.0 / OpenID Connect Integration.

administrator

A user assigned to manage resources within a project or application. There are two levels:

• Project administrator — can manage any entity in the project (applications, services, service accounts), except the project owner.

• Application administrator — has one of two roles: Developer (manages the application schema and API keys) or Users Manager (views the user list and assigns roles).

A project can have any number of administrators. Contrast with owner, see Owners and Administrators.

application

Application is a logical entity, allowing to break a project into separate subsystems, see Application section.

application schema

A structured definition of the permissions system within an application, consisting of a combination of permissions and roles. The application schema allows developers to assign roles to users, defining what actions they can perform within the application. By establishing an application schema, developers maintain control over user access, ensuring a flexible and organized permissions structure, see Application Schema.

authorization code

A temporary, one-time code returned by the authorization server after user consent in the OAuth 2.0 Authorization Code Flow. Must be exchanged for an access token and ID token, see OAuth 2.0 / OpenID Connect Integration.

bound token

A JSON Web Token (JWT) issued during user authorization and bound to a specific application. Grants access to user permissions. Contrast with unbound token, see JSON Web Tokens.

device factor

A random value generated at login time and stored in the browser. Included in the JWT payload as a hash (fac field). Because only the original browser holds the factor, the token can only be used from that browser. Required for most permission-related API operations, see JSON Web Tokens.

ID token

An OpenID Connect token returned alongside the access token after successful OAuth authorization. Contains identity information about the user (email, nickname, etc.) and has a 1-hour lifetime, see OAuth 2.0 / OpenID Connect Integration.

JSON Web Token (JWT)

A JSON Web Token (JWT) is a compact, secure token that transmits user data between parties. It is signed by the issuer for authenticity and is commonly used for authentication, allowing access across services without re-authenticating. JWTs may include additional data like permissions and have a limited trust period, determined by the service, see JSON Web Token (JWT).

OAuth 2.0 / OpenID Connect

An industry-standard authentication and authorization protocol. Gaijin SSO implements the OAuth 2.0 Authorization Code Flow with OpenID Connect 1.0, enabling secure user login and token issuance for third-party clients, see OAuth 2.0 / OpenID Connect Integration.

owner

A project-level role with the highest authority. Owners can add or remove administrators and other owners. Every project must have at least one owner, see Owners and Administrators.

permission

Permission is an atomic unit of access that grants a user the ability to perform a specific action, see Roles and Permissions.

private role

A role assigned within the application scope, restricted to specific users performing administrative or service-related tasks, such as managers and support personnel. Private roles are assigned by the application developer and are not available to all project users, see Public and Private Roles.

project

Project is the top-level entity for Gaijin Central: it can contain one or more applications, allows you to connect the necessary services depending on your needs, allows flexible access management for administrators to applications and services, see Project section.

protected role

A role marked as protected, which restricts the permissions it can contain and who can modify it. Only protected roles can include protected rules from the application schema. Changing a role from public to protected removes it from all existing user project access records, see Role.

public role

A role assigned at the project level, available to all users with project access. Public roles can be assigned by users connecting the application as a service, see Public and Private Roles.

refresh token

A long-lived OAuth 2.0 token with a 30-day lifetime that allows clients to obtain new access token and ID token values without requiring user re-authentication. Refresh tokens are rotated on each use, see OAuth 2.0 / OpenID Connect Integration.

request signature

A digital signature added to the Signature HTTP header in server-to-server requests. Transmitted as a Base64 URL-encoded byte array containing version, timestamp, and HMAC data. Used to verify request integrity and authenticate the application, see Server-to-Server Signed Requests.

role

Role is a set of permissions assigned to a user, granting them the necessary access rights to perform required actions within the application. see Roles and Permissions section.

role condition

A logical filter attached to a role that determines when the role applies to a user. Supports conditions based on domain, user ID, tag, IP address, purchase, and logical operators (and / or), see Role.

service

Service is a self-contained unit of functionality accessible over a network. Performs certain tasks independently and allows extending the functionality of applications, see Services section.

service account

A special user account created for external applications or services to perform automated functions within a project. Has a UID and a system-generated token, but cannot log in with an email and password, see Service Accounts.

service JWT

A JSON Web Token (JWT) issued by a service rather than by the SSO. Used as an alternative to device factor in API requests, enabling service-to-service authentication. Can be either a generated service JWT (created dynamically per request) or a predefined JWT, see JSON Web Tokens.

SSO

Gaijin’s centralized authentication service hosted at login.gaijin.net. Acts as the certification authority for the platform: issues and validates JSON Web Token (JWT) tokens, signs tokens with its private key, and supports OAuth 2.0 / OpenID Connect, see JSON Web Tokens.

trust window

The time period during which a service trusts a JSON Web Token (JWT) without re-verifying user permissions. Typically 5 minutes, up to 24 hours for lower-risk scenarios. Because permissions can change after token issuance, the trust window limits exposure to stale permission data, see JSON Web Tokens.

UID

A unique numeric identifier assigned to each user account in the Gaijin system. Used to reference users in API requests, project access management, and service account operations.

unbound token

A temporary, one-time JSON Web Token (JWT) derived from a bound token. Not bound to any application; used to transfer authentication between applications. Can only be exchanged once — attempting to reuse it returns an error, see JSON Web Tokens.

user group

An entity that aggregates users based on membership conditions (domain, tag, purchase, etc.) or explicit user additions. Groups can be granted permissions within project applications and services, see User Group.