AUTH.AS Protector service for websites protection

Following this guide, we will look into the process of AUTH.AS Protector service setup, together with two-factor authentication system, for the protection of any web-resource on the network from unauthorized access.


Service description

AUTH.AS Protector service was built to secure a web-resource from unauthorized access from external network. In fact, the Service is a customized proxy-server (Reverse Proxy), providing two-factor security check, without additional integration of the protected web-resource with AUTH.AS system. In this case, all traffic from the client to the web resource goes through AUTH.AS Protector, which increases the safety of the web resource from all sorts of attacks and reduces its load. One of the key advantages is the ease of connection - no changes or additional installations need to be done on the protected web resource


Structure of the Service

Let's take a look at the processes below, to illustrate, how AUTH.AS Protector works. In most cases, when a client requests some web content from a website, it can be shortly described like this:

  1. A client types some web-address in it's browser (ex., Browser sends this address (URL) on a public DNS server, to resolve it into IP address.
  2. DNS server replies with IP address, which corresponds with web-site name, like, for example,
  3. Browser sends a web request to that IP address, that it just got from DNS (, in order to receive web content.
  4. Website sends requested content to the client browser and browser displays it to the end-user.

When using AUTH.AS Protector, the process of accessing website and getting web content changes:

  1. A client types some web-address in it's browser (ex., Browser sends this address (URL) on a public DNS server, to resolve it into IP address.
  2. DNS replies with AUTH.AS Protector service IP address (ex., because website is now protected from unauthorized access.
  3. Browser sends a web request to IP to permit access to the requested website ( AUTH.AS Protector asks for the username and password.
  4. AUTH.AS Protector validates those entered credentials using API.
  5. If validation was successful, it goes further.
  6. Since only AUTH.AS Protector knows the real website IP address (ex.,, it requests web-content from this IP.
  7. That website content is being transferred to the client browser.
  8. Browser gets the requested content from AUTH.AS Protector service and displays it to the end-user.

Systems setup

  • At system side, we need to generate API_KEY of the secured domain and setup user accounts for those, who are supposed to have access to the secured web-resource. The easiest way is to send us an email to, with authorized user emails list and we will complete the setup for you. If you're still interested in setting up the system by yourself, then you're just a couple of clicks away:

    Add authorized users and assign tokens for them:

    More detailed manuals on how to manage system: Managing users и Managing tokens.

  • Please, send us an email to, with DNS name of your website, it's external IP address(es) and that API_KEY, that you've just generated in the first step. We will set up AUTH.AS Protector for you. If your're using HTTPS connections to your web-resource, please, also attach certificate and secure key from your website. If your web-recourse uses non-standard ports, please, let us know also.
  • After AUTH.AS Protector set up is done, please, make appropriate adjustments into DNS of your web-resource, changing your old external IP address to the IP address of AUTH.AS Protector.

Done! Your web-resource is now protected!

For the end-user, the main convenience of AUTH.AS Protector, is that you only have to perform that last step with DNS set up by yourself. All other set up procedures will be performed by support team.

Please, keep in mind, that full web-site isolation from the outside access can only be achieved by rejecting all network connections to your web-site, other than connections from AUTH.AS Protector. In other cases, unauthorized access could be granted, if the real IP address of the web-resource is compromised.