Using passwords is a nightmare. No one wants to memorize yet another passphrase when our heads are already filled with them. Passwords are a huge vector for security breaches precisely because they place the burden of choosing unique and secure secrets on the user, who just can’t be bothered. We end up having one password for all the important stuff like banking, work, and school, one for the social-medias, and one for all the miscellaneous one-off services we don’t care too much about. The result is that a whopping 59% of people reuse their passwords across services, which means a leak anywhere quickly becomes a liability for the whole web.
The whole log-in dance is stressful too, because every failed attempt is a step closer towards a locked account. The stakes of bungling passwords are so high that oftentimes we admit defeat before even getting to the third try. That “reset password” button is abused so often that it’s pointless to even try to remember the password we’re updating to. Existing solutions on the market are a bunch of contrived band-aid fixes. After all, a password manager is just a notepad where you use a password to guard your other passwords. In the middle of one login flow, users are asked to visit another website, login there, locate credentials of the service they’re trying to use before they can even proceed. Between choosing, recalling, forgetting, and ultimately resetting passwords, logging in has quickly become the Beckett play of the internet.
Supporting passwords is a nightmare too. They need to be encrypted, salted (and peppered), and hashed properly before they can even be stored. Not to mention the upkeep of maintaining account reset features, and all of the business resources allotted to the event of a security breach — every one of which continues to erode the already tenuously-kept trust on the internet.
Magic believes in a password-less future. Instead of contriving password strength validators, maintaining reset flows, and dreading password-related security breaches, websites should log users in with a one-time link sent to their inboxes. Let’s face it, for better or worse, the entire security model of the web is based on email. We already verify accounts with emails. Just check your inbox instead of struggling (and failing) to recall a passphrase. The result is an internet that feels just a little cleaner without all the fussing over secret phrases that can compromise accounts at the drop of a hat.
“All of this sounds great, but way too much work”
Magic is a web SDK
Our service allows developers to add email-link login to their web apps in just a few lines of code. If you have access to a front-end javascript app, try this:
Package Manager:
yarn add magic-sdk OR npm install magic-sdk
Javascript:
import { Magic } from ‘magic-sdk’
…
const m = new Magic(‘pk_test_AACA3438D447C2FD’)
m.auth.loginWithMagicLink(‘your-email’)That’s it.
Our service running on your website. This UI is optional and fully customizable to your brand!
Click the link sent to that mailbox from anywhere to watch this modal disappear, and don’t be afraid to use your phone. On the javascript side, the promise `m.auth.loginWithMagicLink(‘email’)` resolves, and the promise `m.user.getMetadata()` now returns info of the currently authenticated user.
“I don’t like how email link login ruins UX”.
Don’t you hate it when a website sends you a login link, only to log you in on the phone you clicked on the link with? Hey Medium, I was browsing on my desktop, not my iPhone SE! Well, we hear that too. Which is why our service logs your users in on the device where the link was requested. No jarring context switches mean no more losing the thread of what you were doing. In addition to an optional redirect URI for the device clicking the link, we accommodate whatever web experience you’re looking to offer.
What makes Magic different.
We care about the developer experience. Logging a user in should feel simple and clean as if you had rolled the auth yourself. Don’t fiddle with unwieldy dashboard configurations till you’re ready to ship. Very little setup is involved in getting started on the front-end, and we offer a robust admin-sdk that makes it a cinch to integrate your server.
To ensure reliable email delivery, we strive constantly to maintain the best domain reputation for everything we send. We also select mail service providers based on the delivery performance of transactional emails. Our redundancy mechanisms ensure that service interruptions to mail providers don’t keep links from being delivered on time.
Magic is not a centralized identity provider. We are not interested in becoming yet another monolithic data collection entity with tendrils around everything from your users’ names, addresses, credit scores to dating preferences. We believe no one company should be interested in all of this. If your users can prove they own their emails, we help them retrieve keys that identify them to your service. What happens beyond this is none of our business.
Decentralized ID
With Magic, a public-private key pair is tied with every account. A user’s private key PKx is loaded onto the browser, into an embedded iframe inaccessible to you (the developer). An SDK method uses PKx to sign (ECDSA) a cryptographically secure message M that could only have been generated by PKx, and returns M to you. As you might have guessed, it is computationally infeasible to deduce PKx from M, but trivial to verify that PKx generated M. We call this a Decentralized ID Token, and it’s our implementation of W3C’s DID spec as it pertains to an individual user.
Back to the exercise above: your user is authenticated in their browser. Now what? How do they talk to your server? With the ability to generate a time-bound DID Token (M), you can initiate a secure authenticated session with your server as usual. We give you the user’s public key so you can validate the integrity of the message yourself, or use our server-side admin-sdk middleware that hooks seamlessly into your session persistence logic. All of this without ever having to keep any secrets from your users, or placing too much undue trust on centralized identity providers. This is what’s known as zero-knowledge proof of authentication, where trust of the integrity of an access token is ascribed not to oligarchic data-collection entities, but to the very fabric of elliptic curve cryptography itself.
Putting it all together
Life of a login request (loginWithMagicLink):
After step 8, the Magic SDK can start to sign proofs of authentication (getIdToken)
Passwords Suck
All of that was to say: passwords suck and need to be deprecated. As inheritors of the web, we have an obligation to make it cleaner, less error-prone, and easier to use than we found it. Magic is our mission, and passwords are only the tip of the iceberg; there are still many more visions for authentication and digital identity we wish to share. So hop on board with us on a journey towards many more exciting, cyber-future inspired destinations!
Magic is an SDK that lets developers add passwordless login, such as magic links, social login, and WebAuthn, to their app with just a few lines of code.
Learn more about Magic & keep in touch 💜
Website | Documentation | Github | Twitter | Career
