One of the things I’ve always found is that you’ve got to start with the customer experience and work backwards for the technology.” — Steve Jobs
Authentication, at its core, can be characterized as a protocol facilitating communication between two entities: a client application and an authentication server. The client’s role encompasses the collection of user credentials, subsequently transmitting them to the server for meticulous identity verification. This process can be perceived as a simple, yet significant, handshake between the client and the server.
Authentication Handshake between client and server
Cosync Inc., our company, offers a self-hosted authentication solution that is grounded in open source principles and tailored to run on a developer’s own infrastructure. For comprehensive information about our solution, please visit https://cosync.io.
In the late 1990s, web applications emerged, followed by the advent of smartphones in 2008, giving birth to a new breed of user-authenticated applications. These applications necessitated users to provide credentials and undergo a login process before accessing the desired functionalities. User-specific data was conventionally stored in a web server database alongside their credentials and application-specific state information.
During this period, client-side application development typically involved separate teams dedicated to front-end user interface and backend server-side tasks. The backend team took charge of authentication-related responsibilities, encompassing login and signup functionalities, as well as database storage. Communication between the front-end code and backend servers was commonly facilitated through a REST API, leveraging HTTPS function calls, with login and signup operations serving as prominent examples.
During the early days of web application development, the process was characterized by its time-consuming nature, substantial costs, and susceptibility to errors. The maintenance of two distinct teams, each possessing different skill sets, incurred considerable expenses. Furthermore, server-side solutions often faced limitations in terms of scalability and necessitated extensive modifications to accommodate a growing user base. These challenges posed significant hurdles, particularly for rapidly expanding applications that demanded immediate responses, leaving engineering teams struggling to keep up. Additionally, backend teams were burdened with the task of deploying physical hardware in server farms to meet the escalating demands of the front-end.
During the early 2000s, Amazon and Microsoft spearheaded the innovation of virtualized web services, introducing AWS and Azure, respectively. These groundbreaking services presented a shift towards backend-as-a-service (BaaS), effectively abstracting numerous low-level functionalities that had traditionally burdened backend teams. The advent of BaaS liberated developers from concerns surrounding scalability and the need to acquire additional server hardware as the demand arose. This newfound freedom enabled developers to redirect their time and resources towards the front-end development, fostering a more focused and efficient development process.
During this period, a revolution unfolded in server-side database technology. MongoDB, a prominent player in the field, introduced Atlas, an open-source object-based database capable of harnessing the power of AWS and Azure. This innovative solution presented a database-as-a-service model that offered scalability and adaptability to meet the evolving needs of developers. MongoDB’s Atlas emerged as a robust and scalable choice, empowering developers to leverage the full potential of cloud computing platforms.
The technological landscape underwent a significant shift in 2008 with the unveiling of the revolutionary iPhone by Apple, a groundbreaking “smart” phone. This milestone was closely followed by Google’s Android, offering a more accessible smartphone alternative. These mobile platforms brought forth a new wave of user-authenticated applications. Unlike their web counterparts confined to browsers, mobile apps ran directly on handheld devices equipped with substantial computational capabilities and ample storage. Consequently, mobile applications were able to optimize performance through data caching and deliver swift and seamless user interfaces. To cater to the burgeoning demands of the mobile application market, two prominent players emerged in 2011: Firebase and Realm. These companies emerged as pivotal contributors, providing solutions tailored to meet the specific needs of mobile app development.
Firebase set out with the objective of streamlining the complexities associated with mobile backend development. It accomplished this by offering authentication services and hosted databases, effectively simplifying the integration between client-side applications and server-side databases. By doing so, Firebase succeeded in greatly enhancing programmer productivity. One notable advantage of Firebase was its ability to minimize the reliance on intricate REST APIs for communication between clients and servers. This reduction in complexity proved instrumental in empowering developers and facilitating smoother interactions between various application components.
Around the same period, Realm emerged with a distinct focus on creating a robust client-side object database. This endeavor aimed to address the challenges posed by fetching web data from servers to mobile devices, where caching became indispensable in improving performance and reducing network congestion. Realm stood out from alternative solutions like Apple’s Core Data due to its seamless integration of the object model with the client-side programming language. For iOS, Realm provided Objective-C and Swift bindings, while Java and Kotlin bindings catered to Android developers. The beauty of Realm objects lay in their resemblance to other objects manipulated by the client-side program, with the added advantage of persistence across multiple application instances. Initially available for free, Realm gained widespread adoption and found its way onto countless iPhones and Android devices through various applications. Remarkably, despite having fewer than 30 employees, Realm had amassed over 4 billion installs by the time MongoDB acquired it in 2019. In 2018, Realm introduced a game-changing product known as Realm Sync, directly competing with Google Firebase. What set Realm apart from Firebase was its seamless background database syncing, creating the illusion that the application was writing data directly to a local database.
As far as authentication was concerned, initially developers handled authentication as part of the back-end server functionality. Login and signup functions were part of the REST API. The problem with this approach is that it transferred responsibility for authentication on the developer. This cost more in terms of development but could also lead to several security vulnerabilities if not implemented properly. For example, developers might inadvertently store user passwords on their server database rather than an encrypted MD5 hash of the password. And if the server were compromised, so would the user passwords along with the emails. To compound the security issues, users often used the same password for the same email across multiple applications. A leak in one system could translate a security break over multiple applications. Furthermore, a REST API itself could be spoofed and the user would inadvertently be his/her password onto a third party without realizing it. To mitigate this risk, developers would then have to implement phone two-factor authentication as part of their system, to further guarantee the user’s identity.
In 2013, the release of Auth0 provided a focused solution for authentication challenges. This product efficiently managed secure login and signup processes, as well as identity verification on behalf of developers. Additionally, Auth0 offered secure storage for user credentials, relieving developers from the burden of handling lost passwords. This shift in responsibility also freed developers from the legal implications associated with authentication management. Auth0’s success led to its acquisition by Okta in 2021, and it has since gained a significant user base, with over 700,000 developers worldwide relying on its services.
In 2010, the advent of JSON Web Token (JWT) technology provided a means to establish trusted credentials between Internet processes. JWT utilizes public/private key encryption to establish a secure connection. The signer, typically a server-side process, generates a signed JWT token using its private key, which remains exclusive to itself. Conversely, the application, often a client-side process, can verify the signer’s identity by decrypting the signed JWT token using the public key, accessible to all. The essence of public/private key encryption lies in the fact that the public key can only decrypt content encrypted with the corresponding private key. Should decryption fail, the client promptly identifies the JWT token as fraudulent and refrains from proceeding with the login process, ensuring robust identity verification. The rise of JWT has been notable, particularly in the context of the Internet of Things (IoT), where it serves as a dependable method for securing device communication. Notably, since the JWT token itself assumes the form of a JSON payload, it can encompass various claims (data) tied to the user, facilitating the application’s determination of user permissions within its domain. While MongoDB Realm offers support for third-party JWT login providers, it does not currently provide its own JWT solution.
In the modern era, the majority of third-party authentication systems, such as Auth0, have taken the form of Software-as-a-Service (SaaS) solutions. Within this framework, the authentication system assumes the responsibility of safeguarding user credentials and managing authentication requests on behalf of the application. Additionally, these systems provide scalable solutions to accommodate the ever-growing user base of the application. Scalability entails swift response times for concurrent requests and global accessibility for users scattered across the globe. Furthermore, these systems may offer supplementary features like phone-based two-factor authentication or time-based one-time passwords, exemplified by Google Authenticator. The provision of configurable metadata is another attribute, enabling attachment of user-specific details like name and country to their profiles. Advanced authentication systems can even incorporate biometric data, such as fingerprints, retinal scans, or facial recognition, and implement “know your customer” (KYC) protocols to validate users’ background information. When evaluating an authentication system, developers typically prioritize key factors like security, scalability, and cost.
At first glance, Authentication as a Service appears to be a logical evolution, akin to outsourcing server scalability to AWS or Azure with a pay-as-you-go approach. This shift involves entrusting software development and accountability to a third-party provider. However, it is crucial to carefully consider the implications of relying on an external entity for user identity. Key considerations include costs, control, and the inherent risk of service disruption.
When considering Authentication as a Service, the accounting department’s foremost concern is typically the associated costs. SAAS providers usually offer various pricing tiers to cater to different needs. The initial tier often provides free trials, suitable for overcoming technical hurdles during application development, typically accommodating a limited user base of a few hundred users. The second tier involves payment based on the number of active users or login/signup transactions. The highest tier, known as the “enterprise” plan, requires direct interaction with the sales department. It’s worth noting that these services can be quite expensive. For instance, Auth0 may charge up to $25,000 per year for 10,000 active users, and as the user count exceeds 100,000, the costs can significantly impact profitability. While certain security requirements, like those in financial banking software, may justify investing in Auth0, many applications fall into categories where security needs and scalability are less demanding, making the price tag prohibitive. For example, a prayer group meetup application for the Church of the Nazarene may not require such robust security measures. In such cases, the self-hosted COSYNC JWT authentication service proves to be a suitable alternative.
A significant concern regarding third-party services is the issue of control and technical aspects. By opting for a third-party service, developers inherently surrender a level of control. User authentication, in particular, presents challenges due to the critical nature of user credentials and associated metadata. If the developer fails to settle the authentication provider’s bills, the application won’t function, and prices can fluctuate. Authentication is intricately intertwined, unlike services provided by AWS or Azure, making it difficult to transition seamlessly from one Authentication SAAS provider to another while migrating users. In practice, when a company selects an Authentication SAAS provider, it often becomes a long-term commitment for the entire lifespan of the application. From a control perspective, developers benefit from choosing an authentication solution that is both open source and integrates smoothly into their existing technology stack. The COSYNC JWT authentication server was specifically designed to meet this requirement. As a guiding principle, developers should only outsource to a solutions provider if the technology can be easily replaced in the future.
As mentioned earlier, authentication plays a crucial role in the functioning of an application. If the authentication service fails, the application becomes essentially unusable. When relying on a third-party SAAS provider for authentication, there is an implicit assumption that the provider will maintain 24/7 uptime and remain operational indefinitely. Opting for a well-established provider like Auth0 may seem like a safe choice, considering its parent company Okta’s substantial market capitalization and public trading status. This aligns with the notion, prevalent in the 1970s, that selecting IBM as a vendor was a reliable decision. However, recent events have demonstrated that blindly trusting large companies solely based on their size may not always be the wisest approach. For example, in 2013, Facebook acquired a mobile backend as a service platform called Parse, which powered over 500,000 mobile apps. Developers believed that relying on Facebook’s technology was a secure choice due to the company’s prominence. However, Facebook abruptly discontinued Parse in 2017, leaving developers stranded without servers, support, or a future. Another example closer to the technology landscape is the case of Silicon Valley Bank (SVB), which offered banking services as a SAAS product. In March 2023, the bank, with a market cap four times larger than Okta’s, suddenly ceased operations. Its banking services, including the website, were shut down without any prior notice. When such incidents occur with a service provider or a bank, it feels as if the solid ground beneath your feet crumbles away.
In summary, relying on a third-party provider for authentication introduces risks and costs, making one feel confined within a seemingly impenetrable fortress. Developing an authentication strategy requires careful thought, as once implemented, it becomes difficult and expensive to modify. The control over authentication should reside with the application developer rather than being an external burden. Addressing these concerns, the self-hosted COSYNC JWT authentication server has emerged as a solution designed to mitigate these risks. In our upcoming discussion, we will explore these intricacies further.
SAAS Authentication Fortress
To overcome the challenges associated with authentication, a self-hosted approach that seamlessly integrates with the developer’s open source stack proves advantageous. At Cosync, we have dedicated ourselves to crafting and implementing such a solution in the form of our self-hosted Cosync JWT Server. For a deeper understanding of our offering, we invite you to visit our website at https://cosync.io.