HexaEight Authentication can accelerate the Application Development process and allows developers to focus on the application code rather than the authentication and the security aspects related to authentication. Our authentication process can be used like a catch all authentication for any application in your realm, by setting a cookie to identity the user and implement Single Sign on within your application code.

Assume you have a number of applications written in various languages by various teams for your end users or employees or customers.  Every application must keep a database of user credentials that are allowed access to the application, and the developer is in charge of user login, logout, and password resets. 

By incorporating our login process into your application, the developer can offload the authentication process to HexaEight Serverless hosted in your premises, allowing them to focus solely on application development and determining the logged in user by invoking a single API from your Application Code.  

End users benefit by having to create a single digital identity using any email address via our Mobile Application and use the same universal Identity to login into any of your applications. End users have an additional benefit of using the same universal identity to even access external applications if those external applications that integrate with HexaEight Authentication.

HexaEight Authentication is not directly beneficial if your application deploys Federated Authentication using OAuth2 Framework. Assume you've used OAuth2 to implement the Client authentication process to a cloud provider like Google, and now you've received an access token and a refresh token from Google to access data specific to the user from Google API servers. 

In this scenario, if you plan to replace Google Open ID Connect authentication with HexaEight Authentication and use our JSON Web token to access Google API servers, this scenario wont work. Our Cookie based JSON Web Token is not a replacement access token that can be used with external identity providers.

However, if you implement OAuth2 Server to Server Flow in your Application code and allow dual authentication by redirecting the user to Google and fetching a long term refresh token and store it in a http only secure cookie, you can then deploy HexaEight Authentication to verify the Gmail user the next time he logs in and use the stored refresh token to fetch data specific to the user directly from Google API servers and display it in your application.  The main advantage of clubbing our authentication with an existing Federated Authentication is that you do not need to  keep the client application logged in for an extended period of time or need to redirect the user to the external identity provider since the refresh token is already available in the cookie to fetch user related information.

HexaEight Authentication allows any authenticated and verified email user to access your application by default, provided they have successfully completed the QR Code verification process. HexaEight Serverless provides the option of filtering authentication based on specific domains rather than individual users.  When a user has been successfully authenticated, the application program can access a cookie or JSON Web token containing the user's information; however, it is the responsibility of the application to determine whether the user is permitted or not to access your application. 

This enables decentralized user authorization in your application by restricting our Platform's role to authentication and delegating the authorization process to your application.  This is incredibly helpful for applications that require a complex application-specific authorization logic implementation that cannot be satisfied by a simple role-based authorization.

Your application only needs to save the user's email address or a hash of the user's email address and complete the authorization process. 

Only the resources associated with a user, as well as authentication logs, are stored on our Platform.  One of the most serious threats to Identity Providers is the constant fear of their user credentials being compromised, which can have immediate consequences for the businesses and applications that rely on them.  However, HexaEight does not have this problem because we do not store user credentials and have built our Platform on a robust infrastructure that is resistant to attacks. However, anyone who is still unsure about implementing our authentication can be assured that no information can be gathered from our Platform in the event of a breach. 

By offloading the authorization process to your application, no information about your application, its users, or roles is stored on our platform, giving you complete control over where and how safely and securely you want to store this information in accordance with your business practices and security policies.

HexaEight Platform DOES NOT STORE USER PASSWORDS.  When our Platform issues a Digital token to a user, the token is protected by a password known only to the user.  We would also like to empathize that THIS DIGITAL TOKEN PASSWORD IS NOT ALSO STORED ON THE USER'S MOBILE.

As a result, the user is responsible for remembering their password and must enter it in the Mobile app prior to authentication.  The user password is encrypted in our mobile application memory as long as the Mobile App is running in the foreground or background, and it is destroyed when the mobile app is closed, at which point the user must reenter the password for that Digital Token.  This prevents passwords from being leaked if a phone is stolen.  Users ONLY need to take extra precautions to protect their email accounts because HexaEight Digital Tokens are issued by verifying their ability to access their email Inboxes. 

HexaEight JSON Web tokens issued our Platform are encrypted and can only be deciphered with an API key. However, all of the usual precautions that are taken when dealing with a JWT should be followed when using our JSON Web Tokens.  Because JSON Web Tokens are stored within an HTTP Only secure cookie, they are not accessible to JavaScript, and thus the JWT can only be exchanged on the server side with a non-cookie based application.  While our JWT is encrypted, we recommend using Transport layer security to send this token to other non-cookie server-based applications to avoid token leakage, even though the validity of each issued JSON web token is only for an hour.
 
Here is a sample cookie JSON Web token that is encrypted and issued by our Platform.