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:
- Data Reporting: ID’ing and able to track who/when/how long users attended.
- Security: Preventing harmful elements from participating in class. Access to only authorized users
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:
- 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 are limitations with shared devices
- IP Address:
- Has limitations if users are on a shared device
- Disposable urls
- Ex: Slack sends over a magic link.
- Email users a secure link to join class and verify identity.
- Session cookies:
- Read more: https://hackernoon.com/all-you-need-to-know-about-user-session-security-ee5245e6bdad
- Using captchas as a second layer:
- Prevents spam bots from making frictionless requests
- Alternate Social logins like FB/Google
- Super cookies also known as Zombie Cookies
- Evercookie is pure evil, further reading https://github.com/samyk/evercookie
- Single Sign on (SSO) patterns
- Canvas Fingerprinting
- QR Codes:
- https://qifi.org/ QR codes via JS.
- Phone call:
- Participant receives phone call to join- “state your name”
- SMS Verification:
- Either verification code sms or link
- Ad based APIs like DoubleClick
- USB Security Keys:
- Universal Links:
- Facial Detection:
- Can be an option to explore down the line, Apple still has to figure out the kinks on this
- Web Authentication (WebAuthn):
- How Github started supporting https://news.ycombinator.com/item?id=20760195
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.