Перейти к содержанию

Authorization Service


This service is designed for centralized user authentication and authorization management, as well as differentiation of access to cloud services.

List of features, implemented by this service within the system:

  • Merchant management (Merchants and permissions)
  • Merchants' keys verification and permission token generation (Permission Tokens)
  • User creation (Users and permissions)
  • Security factor management (Security Factors)
  • Security factor verification and security token generation (Security Tokens)
  • Security token verification and permission token generation (Permission Tokens)

Basic Concepts and Terms


An organization or a private person is a cloud user and has an assigned merchant ID and a corresponed merchant key, which attribute requests to merchant's cloud services. All of the system accounts that merchant creates unambiguously become attached to this merchant upon creation using merchant ID.


Unique UUID, assigned to a merchant upon creation. Used for merchant identification in the system.


API key, assigned to a specific merchant ID. It has a regulated list of permissions, that give access to a certain cloud service functionality. It is possible to create several keys with different permissions (as well as their rotation) for each merchant.


System's end-user, creating API requests using merchant. Every user account is assigned a unique account ID upon creation, and a merchant attaches to it. To get access to cloud functionality, it is required to pass security factors verification of this user.


Unique UUID, assigned to a user account upon creation. Is used for user identification in the system.


A set of data, provided by the user, that at the same time identifies it in the system and verifies the account ownership. When a sufficient set of verified security factors is provided, a user can get some specific permissions in the system. A specified set of required factors depends on the requested permissions. To get a permission token using security factors, it is necessary to get a security token for each provided factor first.


The knowledge factor of access credentials identifies account by its unique user name and verifies account ownership using password. All the details are provided simultaneously, and if successful, a corresponding security token is generated.


Case-insensitive, unique within the system, utf-8 string.


Case-sensitive utf-8 string.


Email address ownership factor. It identifies account by its unique email and verifies account ownership by means of email verification (with sent code). Verification occurs in two steps: the first request sends an email with a verification code, the second checks code compliance and returns security token.


Case-insensitive, unique within the system, existing email address.


Six-digit verification code sent to an email address to check ownership.


Short-lived JWT-token that confirms successful verification of a security factor. Contains information about a certain factor type and its association with user.


A set of API descriptors, enumerating permitted API sections. For instance, a read permission gives access to cloud services API sections, marked by read descriptor.

At this moment, the following list of possible permissions is supported:


Short-lived JWT-token, provided containing permissions list. May or may not be attributed to user account by its id, but contains merchant id anyway. Generated in two ways: when correct security tokens are provided (in this case token is associated with the account), or by providing merchant key (in this case token is associated merchant only). Some permissions can be gained only by security factors (e.g., security, for modifing security factors by the user), and some only by means of merchant key (e.g., register, to create new user accounts).


Long-lived JWT-token, which allows to refresg permission token without providing sencitive data.