# User Authorization

This section will provide a detailed explanation of user authorization. If you are already familiar with HexaEight machine-to-machine authentication, you know about the source-identifier concept used to identify the source for fetching an asymmetric shared key from HexaEight Platform.

However, in HexaEight Sessions, there is no Login Token associated with the Email Address. Instead, the Login Token is issued for the Generic Resource, making it impossible to use the Login Token associated with the HexaEight Session to identify the source for other users.

User privacy and security are critical considerations when authenticating users, and we have already highlighted that login tokens for users are only issued through the official HexaEight Mobile App. To address these challenges, we developed an authorization server called HexaEight Token Server, which manages the authorization aspect of client applications.

HexaEight Token Server is the official Authorization Server provided by HexaEight Platform. It is responsible for the following three roles:

Verify two-factor authentication codes and issue a Source Identifier for HexaEight Sessions
Validating and issuing Client-tokens a.k.a asymmetric shared keys to authorized HexaEight Sessions in Client Applications as well to Resource Servers.
Issuing Client Identifiers to Client-Applications

HexaEight Token Server acts like a broker between an HexaEight Session and a destination Domain Or Generic Resource. However, it can also act as an intermediatory between multiple HexaEight Sessions. This enables the development of a comprehensive first-party Client application that can interact with other users as well as Resource servers in a more versatile manner.

Client Identifiers - Issued by Token Server To Client Applications
Source-Identifier - Issued by Token Server To HexaEight Sessions
Client-Tokens - Issued by Token Server To HexaEight Sessions Or Resource Servers Used In HexaEight Encryption and Decryption process inside Client Applications

%%{init: { 'theme': 'forest' } }%%
erDiagram
    HexaEight-Token-Server ||--|| Resource-Servers : Issues-Client-Tokens
    HexaEight-Token-Server {
    Responsible For-Issuing-Source-Identifiers
    }
    HexaEight-Token-Server ||--|| HexaEight-Session-User-A : Issues-Client-Tokens
    HexaEight-Token-Server ||--|| HexaEight-Session-User-B : Issues-Client-Tokens
    HexaEight-Session-User-A ||--|| HexaEight-Session-User-B : Direct-Interaction
    HexaEight-Session-User-B ||--|| Resource-Servers : Direct-Interaction

HexaEight Token Server is also responsible for creating Client Applications. A Client Application created by HexaEight Token Server A is treated as a first party Client Application for Token Server A, but is treated as third party Client Application for Token Server B.

%%{init: { 'theme': 'forest' } }%%
erDiagram
    HexaEight-Token-Server-A ||--|| Client-Application-168 : Authorizes
    HexaEight-Token-Server-A {
	Issues Client-Identifiers
    }
    Client-Application-168 {
	Contains HexaEight-Sessions
	Treated As-First-Party-Application
	Can Interact-With-Resource-Server-As-Third-Party-Client-App
    }
    HexaEight-Token-Server-B ||--|| Resource-Server : Protected-By
    HexaEight-Token-Server-B {
	Issues Client-Identifiers
    }
    Resource-Server {
	Can Interact-With-First-Party-Client-Application-861
	Can Also-Interact-With-Third-Party-Client-Application-168
    }
    Client-Application-168 ||--|| Resource-Server : Direct-Interaction
    HexaEight-Token-Server-B ||--|| Client-Application-861 : Authorizes
    Client-Application-861 {
	Contains HexaEight-Sessions
	Treated As-First-Party-Application
	Can Interact-With-Resource-Server-As-First-Party-Client-App
    }
    Client-Application-861 ||--|| Resource-Server : Direct-Interaction

HexaEight Token Server issues Source Identifiers to HexaEight Sessions only after verifying the authenticity of the session by challenging it to claim an Encrypted Captcha QRCode. The user claiming the session must decrypt the captcha using an email login token and enter a 5 letter Captcha, which can only be performed by the user through the official HexaEight Mobile App on their mobile phone.
HexaEight Token Server can issue Source Identifiers to Resource Servers that need to communicate with HexaEight Sessions in First Party Client Applications. To identify Resource Servers and issue a Client-Source-Identifier, HexaEight Token Server uses machine-to-machine communication instead of Encrypted QR Code-Captchas

Step 1

%%{init: { 'theme': 'forest' } }%%
erDiagram
    HexaEight-Token-Server-A ||--|| Client-Application-168 : Sends-Encrypted-Captcha-Code
    Client-Application-168 {
	Displays Encrypted-QR-Code
    }
    Client-Application-168 ||--|| User : Scans-Encrypted-QR-Code-Using-Mobile-App
    User  {
	Enters Captcha-Code-Value
    }

Step 2

%%{init: { 'theme': 'forest' } }%%
erDiagram

    HexaEight-Token-Server-A ||--|| Client-Application-168 : Issues-Source-Identifier
    HexaEight-Token-Server-A  {
	Verifies Captcha-Code-Value
    }
    Client-Application-168 {
	Sends Captcha-Code-Value-By-Encrypting-Request-Using-HexaEight-Session
    }

HexaEight authentication relies on encryption to implement the authentication aspect and does not issue access tokens post-authentication.
Authorization is baked into every request, allowing the destination to decide on the authorization scheme to allow or deny access to the request.
HexaEight Token Server implements a modified version of CASBIN policies that does not require every user to be created on the Token server, thus it easy to configure the Token Server to allow all users belonging to a single email domain or multiple email domains instantly using a single policy
HexaEight Token Server provides flexibility to implement distributed authorization, allowing for easier management of authorizations across boundaries such as applications, systems, and machines with different stakeholders.

%%{init: { 'theme': 'forest' } }%%
erDiagram
    HexaEight-Token-Server-A ||--|| Client-Application-168 : Authorizes
    Client-Application-168 {
	Each HexaEight-Session
	Can Implement-Its-Own-Authorization
	To Allow-The-Session-To-Communicate-With-Only-Specific-Users-Or-Resources
    }
    HexaEight-Token-Server-B ||--|| Resource-Server : Protected-By
    Client-Application-168 ||--|| Resource-Server : Direct-Interaction
    HexaEight-Token-Server-B ||--|| Client-Application-861 : Creates-And-Authorizes
    Client-Application-861 {
	Each HexaEight-Session
	Can Implement-Its-Own-Authorization
	To Allow-The-Session-To-Communicate-With-Only-Specific-Users-Or-Resources
    }
    Client-Application-861 ||--|| Resource-Server : Direct-Interaction
    Resource-Server ||--|| Authorization-Server-1 : Contacts
    Resource-Server {
	Uses Side-Car-Authorization-Server
	To Implement-Its-Own-Authorization
    }

Source-Identifiers issued by HexaEight Token Servers for HexaEight Sessions inside Client Applications are completely different from the source-identifiers used in machine-to-machine communication for identifying each other.
These Source-Identifiers issued by an HexaEight-Token-Server-Resource can only be used to request Client tokens from any instance of the same Token-Server-Resource.
Multiple instances of the same token server can be hosted with time code synchronization to enable any instance of the toke server to identify a Source-Identifier.
Every token server uses the concept of Self-Encryption-Using-Time-Codes to issue a Source-Identifier

Summary

HexaEight Token Server is responsible for the following

Issuing Source-Identifier to HexaEight-Sessions using Two-Factor-Authentication
Issuing Client-tokens a.k.a Asymmetric shared keys for Client Applications based on authorization policies
Issuing Client-Id To Client Applications and implementing Client-Id specific authorization policies

Source-Identifiers issued by HexaEight Token Servers are not the same source-identifiers used in machine-to-machine communication.