Self-hosted servers #
In a typical SAAS authentication model, a company that offers authentication services on behalf of a mobile application provides a REST API for accessing those services. The SAAS system is responsible for providing the server infrastructure to store user data and validate authentication requests. It also ensures scalability to accommodate the application’s user base in terms of size and geographical reach. The SAAS provider maintains a 24/7 uptime and can handle a high volume of real-time authentication requests, potentially reaching hundreds per second, if necessary.
Relying on a SAAS authentication service offers benefits such as relieving the developer from concerns about scaling issues and response times. However, the drawback lies in the possibility of rapidly escalating infrastructure costs as the application gains more users. Additionally, once an application becomes dependent on a SAAS authentication provider, the expenses involved in transitioning away from this architectural setup can become quite prohibitive.
The aim of the CoSync Auth authentication system was to reconfigure this architecture, so to speak. Instead of adding an additional SAAS authentication provider, the system leverages the existing infrastructure of cloud-based applications. The idea is to build the authentication process on top of the developer’s infrastructure, which already handles server scaling for data storage and internal REST API requests.
For instance, a typical MongoDB App Service developer is likely to utilize a MongoDB Atlas Cluster to store application data and user information. With the CoSync Auth authentication system, the same infrastructure can be used to store authentication user data. Similarly, if the developer is already using a cloud server provider like Microsoft Azure to host their internal REST API server, they can utilize Azure to run an App Service dedicated to managing the Authentication stack.
By adopting this approach, MongoDB and Azure manage the scaling issues for the database and REST servers, respectively, eliminating the need for an additional SAAS authentication provider that essentially offers similar services at a higher cost for the developer.
What are hosts? #
The concept behind the Self-Hosted CoSync Auth authentication server centers around a host, which functions as a Node.js process hosted on a developer’s server. The host stores its data in a MongoDB Atlas database, under the developer’s control, and is managed through the CoSync Portal. In essence, a host represents an active instance of the Self-Hosted CoSync Auth authentication server. The server’s code is fully open source and can be accessed on the GitHub repository here:
As a host operates as a Node.js process, it necessitates a server to run on, and a REST API URL to expose its functionality. This URL serves a dual purpose, being used both by the developer’s application to access the CoSync Auth authentication functions and by the CoSync Portal to manage and configure applications within the host. Further in this document, we will provide detailed instructions on how to set up a host.
While we recommend using Microsoft Azure to set up hosts, it is also possible to utilize any Linux device running Node.js for this purpose.
After successfully setting up and adding a host to the CoSync Portal (detailed below), the developer will see it displayed as follows:
When a developer clicks on a host, they are presented with all the applications associated with that host, as shown below.
Advantages of Self Hosting #
By opting for the self-hosted CoSync Auth solution, developers gain a significant level of control over their infrastructure stack. One notable advantage is the absence of dependency on a proprietary service that might unpredictably raise prices in the future. The self-hosted CoSync Auth server is open source and operates on the developer’s own servers. Even if CoSync were to cease operations, the developer’s application would continue to function. The only charges incurred are for accessing the CoSync Portal, an administrative panel that facilitates configuration of CoSync hosts and applications through an intuitive graphical user interface. If the CoSync Portal becomes inaccessible, developers can still use the CoSync Auth command line interface (CLI) to manage their self-hosted server.
Another benefit is that all user credentials and associated metadata are stored within a MongoDB Atlas cluster rather than being held behind a SAAS authentication provider’s firewall. This allows developers to inspect and manipulate user data using the comprehensive toolset provided by MongoDB Atlas, as well as seamlessly integrate it into other backend systems.
Lastly, if a developer decides to switch to a different authentication provider, the user credentials linked to a host can be exported to a collection of CSV files. While it would be regrettable to see a developer leave the CoSync Auth ecosystem, the company would accept their decision without heartbreak. In terms of server scalability, the CoSync Auth authentication solution can scale as effectively as Microsoft Azure, which offers high scalability based on the developer’s allocated resources and associated costs. Similarly, from a data perspective, the scalability of CoSync Auth aligns with MongoDB Atlas, a highly scalable database platform.
Regarding security, CoSync Auth inherits the robust security measures implemented by MongoDB. It is expected that developers will apply the same level of diligence in securing CoSync Auth user data as they would with their application data stored on MongoDB Atlas. Notably, MongoDB Atlas employs IP whitelisting, making it challenging for external parties to breach the system’s defenses.
The self-hosted CoSync Auth authentication server is particularly well-suited for smaller mobile applications that have relatively simple authentication requirements and limited budget to invest in a comprehensive SAAS authentication provider. While there are certain authentication categories, such as fintech software or medical records access, where CoSync Auth may not serve as a direct replacement for Okta’s Auth0 product, there are numerous applications that don’t necessarily require the same level of sophistication or incur high costs.
For example, applications like a login system for a swimming pool controller may not warrant the complexity or expenses associated with advanced authentication solutions. CoSync Auth fills the gap by providing an open-source alternative that seamlessly integrates into a MongoDB developer’s stack at a significantly lower cost.