Why doesn’t Glide allow phone numbers to be the way people login?
Surfacing a 2021 thread explaining this feature:
Allowing a user to create an account with their phone number and to receive a magic link via text would be the ideal login method for my use case.
It seems Glide opted for methods 3, 4 and 5, which are among the most secure, short of using a hardware key or an authenticator app. Seems like a reasonable choice.
According to Lumo:
Sign‑in Methods – Security vs Practicality
| Rank (most → least secure) | Method | Why it’s secure (or not) | Practicality* |
|---|---|---|---|
| 1 | Hardware security key (FIDO2 / WebAuthn) | Private key never leaves device; phishing‑resistant; no shared secrets. | ★★ (requires user to own a key, but integration is straightforward for developers). |
| 2 | Authenticator app TOTP (e.g., Google Authenticator, Authy) | Time‑based one‑time codes add a second factor; secret stored only on device. | ★★ (needs user to set up an app; widely supported). |
| 3 | Password‑less “magic link” sent to a verified email | No reusable password; link expires quickly. Security hinges on email account protection. | ★★ (very easy for users; minimal UI friction). |
| 4 | Enterprise SSO (SAML / OpenID Connect) with MFA | Centralized identity with strong policies; can enforce hardware keys, biometrics, etc. | ★ (depends on corporate infrastructure; good for B2B apps). |
| 5 | Social OAuth login (Google, Facebook, Apple, Twitter…) | Leverages provider’s security (often includes MFA); risk if provider compromised. | ★★ (users already have accounts; low friction). |
| 6 | Phone‑based push‑notification MFA (e.g., Duo, Auth0 Guardian) | Approve login via trusted device; resistant to replay. | ★ (requires extra app but still user‑friendly). |
| 7 | SMS one‑time code | Second factor but vulnerable to SIM‑swap and interception. | ★ (ubiquitous, no app install needed). |
| 8 | Email‑and‑password | Traditional; security depends on password strength & storage practices. | ★★ (most familiar, but prone to reuse and phishing). |
| 9 | Username (or email) only | No authentication beyond identifier; essentially insecure. | ★ (rarely used alone). |
*Practicality scale:
★★ = high – easy for users, low setup friction.
★ = moderate – requires extra steps/apps or organizational setup.
Takeaway: For a new web/app product, aim for hardware‑key or TOTP‑based MFA as the default, fall back to magic‑link or social login for frictionless onboarding, and avoid relying solely on passwords or SMS where possible.
Also, via the Twilio integration, you can generate PIN-texts.
this is super helpful @nathanaelb.
based on email registration, people are forgetting which email they used and then sign in with a new email which results in 2 or 3 user accounts. then I have to go and delete the last one with the risk that it was wrong, etc
I’m just trying to find a better way to authenticate and manage operations.
Just in case, you’ll find the authentication options under >Settings >Access >Authentication.
I remember reading somewhere that SMS-based authentication is weaker than most “modern” alternatives. People are used to email+password or SMS PIN, but email+password is weak when passwords are themselves weak or reused, and the protocols used for SMS PINs are not secure by today’s standards.
