# Authentication and Authorization
Authorization and Authentication is a group of services that provide multi-layer security via the OAuth 2.0 specification. User accounts, OAuth 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. Each service we discuss also has a more detailed guide
An environment is the top-level container for applications and data of a single deployment of AccelByte’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 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 for more detailed information.
# IAM Clients
IAM clients can be thought of as the applications that access the platform, such as a game server or launcher. Any application that wants to interact with the AccelByte platform will do so through an IAM client. IAM clients are defined in specific namespaces.
See the IAM Clients documentation for more detailed information.
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 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 for more detailed information.
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 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
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.
# 3rd Party Platform Login
When you publish your game through 3rd party platforms such as Steam, Epic, or PSN, you can enable players to log into your game or platform using 3rd party credentials. This will create a headless account in your game or platform for that player, with a user ID tied to it. For more information about using 3rd Party Platform logins, see the 3rd Party Platform Integration documentation.