Background
Getting authentication (authN) and authorization (authZ) right is vital to modern applications identifying legitimate users while controlling access to system resources. This process can be daunting for the novice as one wrong turn breaks the mantra - "a chain is only as strong as its weakest link." To the uninitiated, authN answers the question: is the user who they claim to be? Authentication precedes authorization but not the converse. AuthZ is primarily concerned with the inquest - are you permitted to access this resource? The journey from authN to authZ starts with the identity of the end-user.
An end-user of any application represents the basic unit or entity. However, it is not practical to fully describe the entity with regards to its attributes and actions. Therefore, an identity depicts a snapshot of properties that characterize an entity in the application's context. Furthermore, an entity can have multiple identities. Consider this instance - a citizen belongs to a country. A citizen can have multiple identification cards (contexts) such as a passport and driver's license. The internet has made it possible to have numerous identities scattered across social media and other online platforms. The average user today has one hundred online accounts, according to research from NordPass. This number could increase under the current global pandemic conditions as people subscribe to more online services. A close inspection of these scattered identities shows a duplication of similar attributes. What attribute is common to all identification cards for any citizen of a country? At least the full name is the common denominator. Asking new users for common attributes such as names creates fatigue on sign-up over time. The user experience is analogous to this scenario: someone walks up to you and asks, "have you eaten?" to which you reply, "Yes." A few minutes later, another person comes to ask the same question and you politely answer. If more people keep asking the same question, the situation escalates from politeness to "I dare you to ask that question again." This common situation can benefit from a federated identity. After a successful identity proof and verification, end users get an access token which they can use to access permitted resources. Next, we look at the authentication and authorization components of the software application. We begin with Firebase for authentication with its perks and benefits.
Authentication
Firebase authentication provides an identity management solution as a service offered by Google. It is not a silver bullet to authentication and leverages industry standards such as OAuth 2.0 and OpenID Connect. Hence, we investigate its benefits and offerings to meet the authentication requirements for your next software application.
Compliance, Privacy, and Security
Firebase authentication enables modern applications to surf the waves of privacy regulations. It meets the standards of the EU General Data Protection Regulation (GDPR). This regulation still applies to software applications having users located in the European Union (EU) despite operating primarily from a non-EU territory. Firebase acts as the data processor in GDPR land, with the business entity behind the software application starring as the data controller. Depending on the end-user roadmap and acquisition plan, the business entity will require a Data Protection Officer (DPO) stipulated in Article 37 of the GDPR. If a DPO is required, Firebase gives you an option to list the DPO on its cloud console. In addition, the California Consumer Privacy Act (CCPA) provides privacy regulations to protect only California residents. Firebase meets the requirements of the CCPA in the capacity of the service provider. Furthermore, Firebase authentication is certified under major privacy and security standards such as ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, and SOC 3.
Authentication Options
Firebase authentication provides several alternatives to authenticate end-users: email, password, phone number, federated identity, anonymous, and custom authentication systems.
Password authentication is the most common authentication method seen in software applications. The Open Web Application Security Project (OWASP) recommends that modern software applications transition to a post-password future, given the public release of over 5 billion password breaches down the years in the current version of the Application Security and Verification Standard (ASVS). The fundamental issue does not stem from the security robustness of password authentication systems but rather a behavioral defect from end-users often overlooked: the average user has numerous online accounts and is likely to reuse passwords across different accounts.; users generally are susceptible to generate weak passwords as it has to be memorable and easily remembered.
Email or passwordless authentication provides a much secure alternative to password authentication. It achieves this through the elimination of user behavior that can compromise the safety of authentication systems. One famous implementation is Slack's magic link login. However, critical observation on authenticating through email links raises concern as email channels also have vulnerabilities, such as phishing attacks and business email compromise (BEC) scams. It is important to note that compromised email accounts can also reset passwords in password authentication. There are no additional risks when comparing passwordless to password authentication. Having a second authentication factor, such as authenticator apps on the email channel, mitigates this risk directly.
Phone number or Short Message Service(SMS) authentication is considered a weak authenticator in the OWASP Application Security Verification Standard. SMS messages can be intercepted and compromised. The current version of the ASVS echoes this woe and recommends that modern applications begin a migration journey devoid of SMS as a future version of the current standard will phase it out. Hence, SMS is a weak link in the security chain whether used as the first or second authentication factor.
Firebase provides several federated identity providers out of the box, creating a frictionless authentication option. These include Facebook, Google, Twitter, Github, Apple, Twitter, and Microsoft. Do software applications using Firebase federated identity authentication have to write code for multi-factor authentication? Examining the problem closely with a focus on user experience brings to light the following observations: federated identity providers have native multi-factor authentication. Rolling out multi-factor authentication code in your software application becomes redundant when already enabled on the federated identity provider. Hence, end-users should be encouraged to use multi-factor authentication ingrained in the federated identity provider. However, end-users must be encouraged to avoid SMS as a second authentication factor to keep the security integrity of the authentication system.
Branding, and UI Customization
Firebase authentication allows for the complete customization of the entire authentication experience for beginners with speed and ease. Nobody sets out to build a bespoke authentication solution unless your business is identity like Auth0. Firebase authentication provides an open-source user interface (UI) library which streamlines building diverse authentication flows for a great user experience. These flows come with the wisdom of years of UX research optimizing the authentication on Google, Youtube, and Android to get you started.
Availability and Scalability
Firebase authentication does not offer service level agreements (SLA). It comes at no cost and does not limit the number of monthly active users (MAU). It charges using SMS verifications which impacts authentication security negatively. If SLA guarantees are a requirement for your business, consider using the Google Cloud Identity Platform or any other identity provider (IDP) that meets your SLA needs. Firebase authentication shines for new ventures and small and medium enterprises who need to cut costs at the onset in uncertain business climates. Despite not having an SLA, you can investigate the availability guarantees from the Firebase authentication status history. For instance, the downtime in 2019 was 1 hour, 48 minutes which is about 3 minutes shy of a 99.98% uptime SLA. The previous year's SLA was much worse, with an approximate 99.4% SLA. As a free service, Firebase operates within certain tenable limits. The authentication API can handle a maximum of 10 million request operations per day.
SDK Integrations
Firebase authentication has support for web, ios, android, c++, and unity platforms on clients. Software development kit (SDK) libraries are available for the supported platforms providing coverage for use cases across mobile, web, internet of things (IOT), and games coupled with documentation. The beta release of the client SDKs provides up to an 80% reduction in file size for the web platform. However, the beta release library will not work with the Google Cloud Identity Platform and the open-source Firebase UI library.
It also offers admin libraries for secure server environments with Node, Python, Java, and Go making it a breeze to work with for serverless architectures.
Additional Considerations
Firebase provides other additional services such as Google Analytics, Cloud Storage, and Cloud Messaging that pair well with Firebase authentication. Analytics helps you target a segment of end-users who can receive messages inside the software application at no cost.
Cloud storage provides a scalable file storage option that uses security rules to provide authorization logic for file access. It integrates seamlessly with Firebase authentication using identity attributes to give permissions to file resources.
For advanced authentication needs such as support for SAML and OIDC, Firebase authentication leverages identity-aware proxies (IAP) to external providers, not covered under the initial identity provider offerings. Furthermore, the native Microsoft federated identity can connect to Azure Active Directory (AD). This access provides support for Web Services (WS) Federation protocol giving access to the Microsoft ecosystem.
Authorization
The client-serverless model is enabling modern applications to encapsulate business and application logic close to the underlying resources. Fauna facilitates authorization logic encapsulated in User Defined Roles (UDR) and User Defined Functions (UDF) using Attribute-Based Access Control (ABAC) for authZ at the database layer. This approach means public clients can talk directly to the database in a secure fashion. Other critical non-database business services run in serverless functions behind a serverless API gateway with inherent authorization logic.
When public clients use bearer tokens, software applications must mitigate cross-site scripting (XSS) attacks. A compromised application can steal bearer tokens - whether in memory or service workers.
Next, we look at architectural components for our serverless identity solution.
Modern Application Architecture
Software application architecture has evolved through generations, giving birth to the modern client serverless architecture. Despite the leaps from generation to generation, the underlying component layers remain almost the same. These components are the presentation, application, business, and data layers.
The presentation layer, also referred to as the view or user interface layer is where users access software applications directly through public clients such as browsers and mobile applications. Public clients, by nature, are not capable of keeping passwords or secrets private.
The application layer does overlap with the business layer. The requirements for building software applications determine the extent of the overlap. The application layer is a gateway to the business layer when encapsulating an API interface to business functionality from the presentation layer. The business layer houses the business rules that govern the set of problems that the application should address. The data layer handles the persistence and storage of data in databases and file storage systems. One factor guiding communication between these layers concerning authorization is that logic for granting permissions should reside close to the resource it controls. The penalty for going contrary is two folds: it increases latency and can lead to a bad user experience; it creates a bottleneck when the server housing the authorization logic is offline while the resource server is online and creates an inconvenience. If the authorization logic and permitted resource reside on the same server, an outage reflects that both are unavailable and notify the end-user of the situation.
In the next installment of this series, we assemble the building blocks to implement a business-to-consumer (B2C) client-serverless architecture and build a serverless authentication solution with Amazon Web Services (AWS).
Top comments (0)