Authentication, Identification & Security without Email Logins

Goal: Security & Identification of users in realtime classes.

Authentication is different from authorization. Former about who it is, authorization is what they’re allowed to do. Email authentication is still the most popular and common form of authentication over the web.

Understanding the Why:

  1. Data Reporting: ID’ing and able to track who/when/how long users attended.
  2. Security: Preventing harmful elements from participating in class. Access to only authorized users

Context:

For many people, email authentication simply works. It doesn't require much thought, it's ubiquitous and there are plenty of libraries, solutions and plug and play options to integrate in your app.

However, a task as simple as remembering your email address and password which many take for granted can be a massive barrier to overcome for others. What if your users deal with various forms of cognitive or visual impairments, or if your users are primarily 65+ years or older. Many telemedicine apps have reported limited success with email authentication. Adoption can drop significantly (over 40-50%) when participants are expected to provide traditional email/password authentication. If one aims to be a highly accessible platform that means offering authentication in a more user friendly way.

So let's explore the holy grail which is to achieve security without barriers to user experience. There are several options architects and developers can choose, but they can have limitations with regards to security.

Security Options sans Email Authentication:


Human Moderation:

  • Manual ID’ing by an operator
  • Depending on type of Signaling API or setup the moderator can see number of participants, authenticate them in a waiting area, and/or manually tag them
  • Moderation includes the ability to remove users or have them stay only after registration.

Not a highly scaleable solution, but can be very user friendly.

Fingerprinting the browser/os/device:

There will be tradeoffs with each option, the idea for security is to have layers.

Zoom’s Security Lessons

They too tried reaching the holy grail of usability and security. Zoom received a lot of flak because of overreaching privacy issues (exposing user’s OS details to anyone)- and by having the software reinstalling itself even after being deleted. Worth exploring the differences and lessons here.

They made a lot of mistakes. They are a native software that has to be downloaded and runs a local server and has rootkey access, fortunately we don’t entertain that sort of risk and are entirely browser based leveraging WebRTC. But essentially their approach here was the ability to send custom urls which were instant join but would prompt the user to open their local app and launch audio/video without permission. Otherwise, the custom url logic can work.