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

Authorization Service

Overview

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

merchant

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.

merchantId

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

merchantKey

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.

account

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.

accountId

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

securityFactors

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.

credentialsFactor

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.

username

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

password

Case-sensitive utf-8 string.

emailFactor

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.

email

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

confirmationCode

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

ellipticFactor

A security factor that utilizes Elliptic Curve Cryptography for registering new accounts.

publicKey

Public key (65-byte base64 string) on the ecdsa-compatible curve.

keyFactor

Access key factor. Is identified by it's unique key.

key

A case-sensitive, base64 string, which is unique throught the system.

securityToken

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

permissions

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:

permissionToken

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).

permissionRefreshToken

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