Authentication and Authorization

Overview

Authentication and Authorization is a group of services that provides multi-layer security via the OAuth 2.0 (opens new window) specification. User accounts, IAM Clients, a robust permission system, and 3rd-party login integration are some of the services provided. In this document, we’ll cover the basics of each system and how they fit together to provide secure, reliable access to our platform.

Components

Environment

An environment is the top-level container for applications and data of a single deployment of AccelByte Cloud’s platform. Applications in one environment cannot communicate with applications in other environments. Environments separate the services and data of different AccelByte customers from each other. Environments can also be used to isolate different builds of the platform from each other, such as when you use a dev environment for development, and a prod environment for live services.

Namespaces

Namespaces are an authorization and grouping mechanism used to control access to services for each of the publisher’s games separately. When defining permissions for clients or roles, you can restrict that access to one or more specific namespaces, or allow access to all namespaces within the environment.

See the Namespaces documentation (opens new window) for more detailed information.

IAM Clients

The IAM service is responsible for controlling access to the platform. In order for game applications, game servers, launchers, or other applications to access the platform, they must be authorized by the IAM service. The IAM service authorizes applications by checking their credentials (Client ID and Client Secret) against the credentials registered for IAM Clients. An IAM Client consists of credentials and a collection of permission tags that determine what the application can access.

See the IAM Clients documentation (opens new window) for more detailed information.

Roles

A role is a way to assign and maintain the same set of permissions for multiple users at once. At its heart, a role is a simple collection of permissions. Roles are defined at the environment level, outside of any namespaces. Roles are assigned to user accounts per namespace, or can be configured to allow the same permissions in all namespaces. This allows you to easily assign groups of permissions to different users for different namespaces to create things like community managers.

See the Roles documentation (opens new window) for more detailed information.

User Accounts

User accounts are the nexus of all other entities in the platform. Accounts are defined at the publisher namespace level, and contain information about every user that has registered with your platform. Accounts can contain personally identifiable information, so permission to access other users’ accounts should be closely controlled. User accounts also contain wallets, entitlements, ban and session information, and any 3rd-party platforms the user has linked.

See the User Accounts documentation (opens new window) for more detailed information.

Permissions

Permissions are how the platform controls and restricts access to resources. Each service and endpoint resource specifies which permission controls access to that resource. Permissions are represented as a tokenized string delimited by colons, along with a [[CRUD]] action. Permissions that have the same string but different actions are considered different permissions.

See the Permissions documentation (opens new window) for more detailed information.

Putting it all Together

Each environment will contain a single publisher namespace. Each publisher namespace will contain one or more game namespaces.

While IAM clients can be defined at either the publisher or the game namespace level, user accounts can only be defined under the publisher namespace. (Technically, you can also define user accounts at the game namespace level as well, but this is more of an advanced scenario outside the scope of this document. Please contact your account manager if you’d like to know more.)

You can create as many IAM clients as you’d like, but most developers only need a few such as game server, game client, dedicated server uploader, and launcher. More details about this can be found in the IAM Clients documentation (opens new window).

Roles will typically be assigned to multiple user accounts. Each user assignment is associated with a specific set of namespaces, indicating the role is applied to that user account only for those specific namespaces. Roles can also be configured to apply its permissions to all namespaces, and when configured this way, this applies to all users the role is assigned to.

Permissions can be defined on clients or roles.

• Role permissions are applied when a user signs into their account, and the user’s session will contain a union of permissions from all roles assigned to that user for the namespace the user has signed into.
• Client permissions are used only when no user account has signed in (such as a dedicated server). Typically used only by confidential clients. Client sessions will have whatever permissions were assigned to the client when the session began.

Permissions strings that begin with “ADMIN:” indicate Admin Portal resources. Roles that have the Set as Admin Role flag enabled are considered to be admin roles and are allowed to sign into the Admin Portal, but must be assigned admin permissions in order to access any specific resources within the Admin Portal. User accounts that have been assigned an admin role are considered admin users, and will appear on the Admins page that can be accessed via the Platform Configurations dropdown in the upper-right corner of the Admin Portal.

Connect Custom Services to IAM using the Server SDKs

SDK Initialization

Before using the IAM service from the SDK, you will need to initialize your server-side SDK to make sure you are authorized and able to perform create, read, update, and delete actions.

Golang SDK Initialization

Before using the IAM service from the Golang SDK, you will need to initialize the SDK by following the steps below:

• Create your IAM Client (opens new window) and assign the necessary permissions to access the Matchmaking service.
• Log in as a Client using the SDK.
• Initialize the OAuth 2.0 service using the following function (opens new window):

Once completed, you can use the Golang SDK to access IAM (opens new window) services from your serverless app.

Python SDK Initialization

Before using the IAM service from the Python SDK, you will need to initialize the SDK by following the steps below:

• Create your IAM Client (opens new window) and assign the necessary permissions to access the Matchmaking service.
• Log in as a Client using the SDK.

Once completed, you can use the Golang SDK to access IAM (opens new window) services from your serverless app.

Authorize

Use the following function to authorize (opens new window) a user or player:

Authenticate

Use the following function to authenticate (opens new window) a user or player:

Log in as a Client

Make sure you have the necessary client credentials to generate an access token (opens new window). You will need this token to log in as a client using the following function:

For simplicity, we have used a wrapper called login_client in the SDK so you don't have to call multiple functions. The SDK automatically detects the values you've set for logging in as a client.

Log in as a User

This login function is used to log in as a user using a username and password. For Golang, make sure you’ve Authorized and Authenticated before performing the following function.

In Python, this function can be used to log in as a user. For simplicity, we have used a wrapper called login_user in the SDK so you don't have to call multiple functions. The SDK automatically detects the values you've set for logging in as a user.

Logout

The Logout function is used to revoke or invalidate user tokens. To implement logout, use the following function: