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

HexaEight Token Server Relationship

%%{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

Client Applications

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

Source Identifier And Two Factor Authentication

  • 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 }

Tokenless Authorization

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