Cook Integrates Magic

With just a little bit of Magic, users no longer need a wallet to use the Cook Finance platform. Instead, their onboarding experience can be as easy as entering their email address.

About Cook Finance

Cook Finance is an open, transparent, and secure platform that makes it easy to access and participate in the revolutionary world of DeFi. Users on Cook are able to select and create various indexes on the platform, across multiple chains like Avalanche, BNB, Ethereum and more. More specifically, Investors are able to auto-execute strategies (Read), DeFI protocols can contribute liquidity through Cook Protocol’s trade routing (Write), and Fund Managers can focus on index strategy creations (Create).

Staying true to their mission of bringing web3 to finance, the Cook Finance platform is governed by a strong community of COOK token holders.

A Magical Synergy with Cook Finance

No matter if we’re on Amazon, the Metaverse or DeFi — one thing we can all agree on is using passwords will always be a nightmare. Now, on top of your password, try remembering a unique 12-word seed phrase for your wallet 🤦‍♀️. Magic removes all of this friction to onboarding onto web3. No need to download a browser extension wallet, no need for a password, and absolutely no seed phrases.

Instead, what you get is all this and more 🚀:

• high conversion UX that supports 38 languages
• highly scalable & enterprise-grade security
• keys that are exportable and Magic never sees

Now that Cook Finance has launched support for Magic, users can seamlessly onboard onto the Cook platform. See the integration in action below! 👇

🥳 We’re thrilled to partner with Cook Finance in making it easier to bring web3 to finance. Any questions about the partnership? Let us know in the comments section below!

Cook Finance Launches Support for Magic was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Pricing matters — it’s often one of the first things to consider when adopting a new product.

That’s why we value transparency not only when it comes to building Magic, but also iterating on pricing. Thanks to all of the helpful feedback from the community, today we’re excited to introduce new and improved pricing plans.

Since we launched metered pricing (based on logins) last summer, we heard from developers across different sized teams that this model made it harder to predict costs. With that in mind, our new pricing is based on monthly active users, and adds clarity to how you and your teams can make the most out of Magic.

Before we share more insight into why we’re updating pricing, let’s cover what’s new.

Note: if you’re an existing Magic customer, these new pricing plans won’t impact your account immediately (and we will be grandfathering in perks!).

Our new plans

The changes to Magic’s pricing make it simple and straightforward to choose the plan that’s most tailored to your needs.

Builder plan

With Builder, you’ll get 1,000 free monthly active users and 100 free login text messages per month. This plan also gives you access to all login methods, access to all 20 blockchains to build a dApp, low-code login form, and User Settings, in addition to the ability to add a custom logo and theme.

For budding startups or indie devs diving into a fun hack project, the Builder plan is a great way to get started with Magic for free.

Want unlimited monthly active users and text messages? Easily upgrade from the dashboard; add your credit card to keep scaling worry-free. After the first 1,000 MAUs free every month, it’s $0.05 per additional MAU. Similarly, for SMS login, after the first 100 texts are free every month, market-rate surcharges apply per text.

Enterprise plan

With Enterprise, you get everything in Builder, plus premium features: multi-factor auth, custom session length, custom email providers (SMTP), additional team seats, and priority support. Volume-based discounts make the Enterprise plan a great fit for customers serving over 20,000 monthly active users. Our Sales team will partner with you to discuss a custom pricing agreement.

The “why” behind these changes

From conversations with developers and teams of various sizes, we learned the pros and cons of the legacy pricing model.

As a result, we aimed to keep the “best of” and added key benefits:

• Free to get started — 1,000 MAUs free, no credit card required
• Suits your needs — whether you’re an indie dev or a large organization
• Pay as you grow — self-serve upgrade to unlimited MAUs and login text messages
• Predictability — unlock volume-based pricing and custom pricing agreements

What you can expect

We are rolling out new pricing for new users on March 1, 2022.

All existing Magic customers will remain on their current plans and will not need to take any action. Our aim is to make the migration as seamless as possible. Over the coming months, we’ll continue giving existing customers a heads-up on the perks that will be grandfathered in, plus the summer migration planned via email and in the Magic dashboard.

Have questions or input regarding the new plans? We’re all ears and more than happy to help. Contact Support on our site anytime.

We can’t wait to see the dApps you build.

New Pricing based on Monthly Active Users was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Moralis Integrates Magic

Moralis, the leading Web3 development platform, now features integration for Magic. Those who buidl dapps on Moralis can enhance their onboarding flow with Magic.

With just a few lines of code, your Moralis Web3 project can have a low-friction, high conversion email-link login (#passwordless). The best part? The sign up info from Magic is automatically synced into the Moralis database and is updated in real-time as users make on-chain transactions.

This integration is in alignment with our goal of bringing the next billion users to web3. Moralis and Magic cuts web3 development time by providing developer-friendly and future-proof infrastructure tools that abstracts away the underlying blockchain tech. The end result? Ivan on Tech, CEO of Moralis answers this question best:

“We couldn’t be happier to launch our Magic integration. It makes total sense for us to combine Moralis’ seamless Web3 development tools with Magic’s silky-smooth user authentication. At the end of the day, this will empower both developers and users, by dramatically reducing onboarding friction for Web3 projects.”

Over 65,000 blockchain projects are already using Moralis’ software and APIs to easily scale their dApps. Now these projects have the opportunity to easily enhance their onboarding flow with Magic.

About Moralis

Moralis truly is the ultimate Web3 development platform. They make it easy to do everything from building Ethereum dapps, creating BSC tokens, designing a great Web3 UI, and so much more.

Under the hood, they’ve got a bleeding-edge blockchain infrastructure that’s fully managed and infinitely scalable. Building your dapp on their infrastructure allows you to build and deploy scalable dapps at breakneck speed as it removes the barriers of manually setting up, managing and maintaining your dapp’s backend.

NFT developers who are wanting to seamlessly build an NFT marketplace, trading interface or token, be sure to check out the Moralis NFT API. As for the developers building dapps and web3 games for the Metaverse, the Moralis Metaverse SDK will empower you to build with Unity and publish on any of the impressive gaming ecosystems supported by Moralis including Xbox, Playstation and more!

A Powerful Synergy

It’s no question that Moralis and Magic forms a powerful synergy to make both developer and end-user lives easier. We look forward to seeing the Moralis Web3 projects that offer a seamless and delightful user onboarding flow using Magic.

👋 Ready to give the Magic and Moralis integration a try?

🎁 Sign up for a Moralis account for free today and then follow the docs!

Moralis Launches Support for Magic was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Passwordless authentication is the future of online security, and promises a future where users don’t need to remember username and password combinations, spend time resetting passwords, and worry about the security of their personal and financial information being stolen.

Passwordless authentication is a fundamental shift in how people will access their tools and information online, and it will provide more security, prevent billions in losses, and create greater transparency.

Let’s explore the different types of passwordless technology and compare a few companies offering passwordless authentication software.

What is Passwordless Authentication?

Passwordless authentication is a method for verifying an internet user’s identity without requiring a password.

Types of passwordless authentication methods in use today including, magic links, one-time passwords (OTP), biometric authentication, and public-private key pairs using blockchain technology.

Is two-factor authentication (2FA) passwordless authentication?

Because the nature of two-factor authentication (2FA) is to add an additional layer of security to passwords, it can sometimes be mis-categorized as passwordless authentication.

However, 2FA methods such as SMS-based authentication would still be considered a one-time password which is a form of passwordless authentication.

3 Types of Passwordless Authentication that Eliminate Single Points of Failure from Centralized PAP-based Authentication

Today’s password authentication protocols (PAP) are designed with centralized intermediaries or organizations that maintain a database of username-password pairs to prove a user’s identity.

The central point of failure of PAP-based authentication puts people at risk of hacks, data breaches, identity theft, fraud, and leaks, all of which can be mitigated with passwordless authentication.

1. Public-Key Cryptography and Blockchain Authentication

Public key cryptography is a form of public and private key authentication, which has been broadly used in the current information world including WebAuthn, machine-to-machine communication, etc.

Public-key cryptography has exploded in popularity in the last decade in large part because of public blockchains like Bitcoin, Ethereum, and Solana that use public-private cryptography to secure blockchain transactions of digital assets and Non-Fungible Tokens (NFTs).

Because blockchain technology is built on top of public-key cryptography, they can be confused as one and the same. However, public-key cryptography doesn’t necessitate authentication with a blockchain.

For example, although Magic enables Web 3.0 platforms to connect to public blockchains like Ethereum, throughout the entire authentication flow there is no interaction with the underlying blockchain; no consensus is involved or required to prove the user’s identity.

How does blockchain authentication work to prove a person’s identity?

Instead of using the traditional method of typing in a username and password, blockchain authentication uses public-key cryptography for self-sovereign identity management.

When a user creates a wallet account on the blockchain, they receive a private key which only they know, and it is paired with a public key that connects them to the wallet address.

To access Web 3.0 applications or complete blockchain transactions, the user signs transaction requests using their private key which authenticates their account access.

How are blockchains secured using public-key authentication?

Blockchains have a variety of security mechanisms to protect the integrity of the blockchain and secure user’s information.

Bitcoin’s Proof-of-Work and Ethereum 2.0’s soon to be Proof-of-Stake consensus mechanisms ensure censorship resistant networks that are practically impossible to hack.

To hack (i.e. modify transactions on a blockchain’s distributed ledger) a malevolent user would need to control 51% of Bitcoin’s hash power, or more than 33% of Ethereum’s stake.

For example, the top four Bitcoin mining pools which power Bitcoin’s Proof-of-Work consensus, control ~60% of the mining power, and to manipulate the network, all four of these independent miners would need to collude.

As long as someone does not have access to your private key, it is highly unlikely for someone to access your wallet or impersonate the identity tied to your public-private key pair.

2. Decentralized Authentication

Decentralized authentication means no single centralized platform, organization, person, or entity is needed to verify your identity.

While blockchain authentication has proven to be a strong use case for decentralized authentication, the two are not the same. You don’t need blockchains to use decentralized authentication methods.

What is an ITF?

Identity Trust Fabric (ITF) is a decentralized mechanism for establishing trust between credentialed users. ITFs act as middlemen by interacting directly with a centralized intermediary.

For example, an ITF could handle all the identification and access requests needed from a centralized party. ITFs decrease the risks of sending your confidential information to an organization.

What are the tradeoffs between decentralized authentication and blockchain authentication?

The main argument for using decentralized authentication methods like ITFs instead of blockchain authentication is the speed and cost of using blockchains.

However, with the emergence of lightning fast layer one blockchains like Solana, layer 2 solutions built to help Ethereum scale transaction throughput like Polygon, blockchains are quickly becoming a faster, cheaper alternative to traditional decentralized authentication protocols.

ETH 2.0 brought Proof-of-Stake (PoS) and sharding to the scaling conversation. These aren’t bad options as they do increase the L1 transaction throughput, but to reach scalability where there are millions of transactions on the network on any given day, PoS and sharding simply aren’t enough.

3. Distributed Authentication

Distributed authentication is a collection of hosts interconnected by a single network. While distributed authentication is the leading choice based on the adoption across the industry, it poses a high amount of security threats.

Two Common Flaws in Distributed Authentication

Two main flaws with distributed authentication are:

1. Unconstrained delegation
2. Unbalanced authority

What is unconstrained delegation?

Unconstrained delegation allows some entity to authenticate you as an individual and also authenticate on your behalf (i.e. impersonate, act as you) to another party.

While unconstrained delegation has benefits such as allowing administrators to update database servers from a web server, it creates an area of exploitation where a hacker with access to admin credentials can unilaterally compromise the system.

Unconstrained delegation can lead to data breaches, exposing millions of confidential usernames and passwords, causing fraud and potentially billions of damages every year.

What is unbalanced authority?

Unbalanced authority is when a specific centralized party or system has information that identifies specific principles within the system (e.g. users).

Unbalanced authority occurs between enterprise businesses where an external business partner is trusted inside the system, allowing them to access company resources.

When the access granted is over-provisioned it allows external companies access to too much sensitive information that can cause harm to the internal organization and their customers.

What type of passwordless authentication does Magic use?

Magic uses public-private key authentication. While the authentication flow doesn’t involve interacting with blockchain, Magic’s authentication allows users to interact with blockchains after they are authenticated by binding the authentication to 16+ different blockchain key generation schemes.

Borrowing security principles from blockchain hardware wallets like Ledger, Magic secures accounts using a combination of hardware wallet security and AWS’s Delegated Key Management.

Software developers can use Magic plug-and-play Software Developer Kit (SDK) to quickly add magic links secured with public-private key authentication to their application.

A magic link is a special URL that represents a login URL, typically emailed to users at login. This link contains an embedded token that authorizes users without requiring a username or password. Magic also supports other login methods like SMS, Social Logins, WebAuthn and MFA.

The Type of Passwordless Authentication You Choose Will Be Different for Each Application’s Security Requirements

Passwordless authentication removes the need to remember passwords and for password managers, and improves upon the security benefits of password-based authentication.

Scalable passwordless authentication tools like Magic help software developers reduce the complexity of securing their applications, while simultaneously hardening security using the best aspects of public-private key cryptography.

With the mainstream adoption of blockchain technology transforming every business sector, having the option to bind authentication with 16+ blockchain key generation schemes helps today’s Web 2.0 companies prepare for the future of Web 3.0.

Passwordless authentication isn’t a zero-sum game. Every business has different needs, and not every type of passwordless solution will fit within the regulatory and compliance needs of each business.

3 Types of Passwordless Authentication for Web 3.0 was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since our last product update, we’ve launched a multifaceted set of capabilities that enable you to do more with Magic.

In this post, I’ll cover the latest highlights and improvements.

Multi-factor Authentication

Developers can now enable multi-factor authentication (MFA) for your users! This capability allows customers to add a layer of security to their end-user accounts. This means a secondary factor is validated along with the existing primary factor to log in to an account. Typically, the primary factor is an email, and a secondary factor is a phone number or mobile device authenticator. The idea is that both factors will need to be compromised to breach an account.

The benefits of enabling MFA include:

• MFA reduces the risk of a compromised account or stolen NFTs by requiring users to provide multiple credentials to access their accounts.
• It protects users from theft. By requiring multiple authentication methods, MFA adds a layer of security from a stolen laptop or device.
• MFA is one of the most straightforward and robust security methods a developer can enable. Magic makes enabling MFA simple with one click in the dashboard.
• It helps your users meet regulatory compliance standards. You should enable MFA if your users must meet HIPAA, PCI, or CJIS compliance standards.

Magic offers MFA through mobile authenticator apps like Authy or Google Authenticator. Email and SMS primary factors are currently supported. Magic will add WebAuthn, and social login primary factors support in the future. To get started, head to the dashboard and enable MFA or read more about the integration here.

Custom Email Provider

Have you wanted to customize the sender of your email magic link login? With Magic, you can now route emails through your Simple Mail Transfer Protocol (SMTP) server. Enabling the custom email provider gives you complete control over where your app’s login email is sent from, as well as the name of the sender.

Magic will send email magic links through your SMTP server as soon as you configure the custom email provider. Disabling the custom email provider will restore sending emails from noreply@trymagic.com. Magic’s custom email provider is compatible with leading SMTP servers. Please visit our docs for more information on how to get started.

Teams

We believe when it comes to building great apps, collaboration is critical. That’s why we are introducing Teams. Every Magic developer is given a personal team where you can invite up to two collaborators to help integrate Magic, update branding, or manage your users. As a collaborator, you will have access to any teams you have been invited to and your personal workspace.

Teams consist of two basic permission levels: a team owner and collaborators. The team owner has complete control over their account and is responsible for billing and managing team members. Collaborators have access to Dashboard functionality to collaborate on any project within the owner’s account. To add members to your project, head to your Magic Dashboard and look for My Team to get started.

Magic Login Form: Privacy Policy and Terms of Service

Our Magic Login Form enables a developer to integrate passwordless login with just 2 script tags. Seamlessly link to your applications Privacy Policy and Terms of Service and have them shown within the Magic Login Form. to new registering users and returning login users. For more information on embedding a URI, review our script options here.

SMS Login for SDKs

SMS Login support has been expanded to our Mobile, Flutter, iOS, and Android SDKs! This release enables developers to easily integrate SMS Login to their applications on any of the supported platforms.

Thank you

As 2021 comes to a close, I want to thank you for your support over this last year! At Magic, we are focused on helping our fast-growing developer community solve complex authentication, decentralized identity, and blockchain problems. So I want to invite you to join the Magic community on Discord, say hello, share product ideas and help others learn in this technology space.

Magic Product Updates: December Edition was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Blockchain technology has come a long way over the last decade, from Bitcoin enabling a secure, decentralized, and trustless way to transfer value, to Ethereum enabling smart contracts and decentralized applications, opening up a wider range of logic with new use cases. We are already seeing a fast rate of adoption in blockchain applications such as decentralized finance (DeFi), non-fungible tokens (NFTs), and decentralized autonomous organizations (DAOs). Many blockchains outside of Bitcoin and Ethereum are also gaining adoption, widening the funnel for the mainstream to enter this space. The time is ripe for multichain.

Layers in the blockchain

Before diving into multichain, let’s first go over the three layers in the blockchain ecosystem: layer 0, layer 1, and layer 2.

Layer 0 (L0) is the base layer among blockchain protocols. Think of it as a blockchain of blockchains. It supports different types of blockchains and allows them to interoperate with one another (e.g. Polkadot and Cosmos).

Today, if you ask anyone outside of the vibrant crypto community to describe blockchain, most would mention: Bitcoin (or maybe Dogecoin). Bitcoin and Dogecoin are both layer 1. Layer 1 (L1) is a blockchain itself and acts as the base layer for applications.

Layer 2 (L2) is a network built on top of the underlying layer 1 blockchain. They are designed to help scale the underlying blockchain, for instance, by handling the computation of many transactions off-chain and submitting a single proof so that users can enjoy fast transaction speed and low gas cost for using the network.

Enter multichain

A multichain world represents the world of multiple blockchains spanning layer 0 to layer 1 to layer 2.

We believe multichain is already here.

Check cryptofees.info, a site that offers usage metrics on blockchains and protocols, today versus a year before today.

A year ago, Ethereum, Bitcoin, and protocols built on Ethereum represented nearly the entire list. Today, new players — L1s outside of Ethereum, protocols built on separate L1s, and various L2s — have gained popularity.

This is not to say Ethereum combined with its ecosystem of protocols is losing its dominance, but rather the total addressable market is being realized faster. This trend is just getting started. Time will tell, but we do not see this as a winner-takes-all-market.

Currently, adoption of multichain seems to be mainly driven by problems stemming from network congestion in blockchains with high demand. This means that since there is so much demand to use the blockchain, unless you pay really high gas fees, your transaction will take a long time to be completed. As a result, other blockchains that focused on scalability (fast transaction times) with low cost of entry (cheaper gas fees) have benefited . Of course, this provokes the question: is it acceptable to compromise security and decentralization for scalability? Is it making the right tradeoffs in the blockchain trilemma model? We will dive more into that in the next section.

At Magic, we would like to share our thoughts on pragmatically taking Web3 to the mainstream, and this starts with focusing our lens from a purely UI/UX perspective.

Scalability and cheaper gas fees as the two main factors that need to be addressed to onboard the next billion Web3 users.

Scalability enables fast transactions. Fast transaction time is already a massive UI/UX improvement. Just look at Amazon losing revenue for every hundred milliseconds of latency. Unless everyone goes down the rabbit hole of how blockchains actually work, people will simply not wait and drop off. Time is precious.

Cheaper gas fees lower the cost of entry for the mainstream. Currently, the “mass” are priced out of using Ethereum (hopefully ETH2 + L2s will address this) for a few reasons:

• Not understanding or appreciating the cost of using a highly secured and decentralized blockchain which does not justify the high cost they need to pay to use the blockchain
• Not having enough capital to use chains with high demand

Thankfully, there is great progress in L0s, L1s, and L2s working in tandem to address those issues and level the playing field for everyone.

Multichain is a choice

What should the right mental model be for deciding which blockchain to pick over another? Is the blockchain trilemma model the only one to look at? There are different implications that you may run into when you compromise one aspect over another. At the same time, this is not completely binary. It is more like playing around with the levers based on your preference or requirements. How much speed does your application need? How much decentralization is enough? How much security is required?

Let’s go over some hypothetical scenarios with respect to the trilemma model:

• Your application does not benefit from the network effect of users that already exist in the blockchain. You are also concerned that you may experience network congestion issues during busy times even in scalable blockchains that could affect your app’s experience. It would make sense to launch your own blockchain on L0. This likely means you would first be prioritizing speed and security over decentralization.
• You are launching a DeFi application and your #1 priority is tapping into the blockchain with the most liquidity and the network effect of DeFi users. Fast transaction speed and low gas cost are nice-to-haves. It would make sense to launch your application on a blockchain with the most liquidity and many DeFi users. People would be most comfortable providing liquidity to the blockchain that is secure and decentralized.
• You would like to tap into a diverse set of user bases. It would make sense to launch your application on multiple chains with different sets of user bases. If the user base is the top priority, perhaps the trilemma model does not matter as much.
• You are launching a NFT game application and you care about fast transaction speed and low gas cost. It would make sense to launch your application on a highly scalable chain that offers low gas cost. This likely means you would be prioritizing speed over security and decentralization.

It does not always have to be systemic related. There could be one blockchain community that really aligns with your ethos and you are also aligned with their vision that they are chasing towards and you would like to be part of their journey. Or you may strongly care about developer experience, and the blockchain project that offers the best developer experience according to your criteria may be attractive to you.

In the end, multichain is a choice.

Magic and multichain brings us closer to mainstream adoption

At Magic, we serve developers.

Magic is empowering developers with the tools needed to put them in the best position to succeed. This is why we are committing to supporting the multichain ecosystem.

We are here to support developers when they have made their choice.

Multichain opens up so many more possibilities and enables us to think bigger — mainstream adoption. Mainstream adoption starts with onboarding.

Magic started out in the world of Web3. We have been laser-focused on helping companies from gaming to NFT marketplaces to media, onboard millions of mainstream users to decentralized apps and platforms, like:

• Async Art
• Fairmint
• Showtime
• Decrypt

Currently we support 18 blockchains, with more coming in the pipeline.

If you’re interested in learning and discussing multichain in more depth, join us on the Magic Discord! If you’re a developer looking for plug and play auth and non-custodial key management, try Magic out for free.

Multichain: What it is, why it matters was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Since our last update, we’ve launched new features that make it even faster for you to get started with Magic and reach more customers.

In this post, I’ll cover the latest highlights and improvements.

Magic Login Form

Now with Magic, you can integrate a full end-to-end login solution to your web app with just two script tags. Your web app is future-proof as all login options and brand settings can be controlled through the Magic dashboard. Magic Login Form provides a complete login solution giving you full access to passwordless login and social logins. Magic Login Form provides a login form optimized for conversion and gives you control over your branding. All customizations can be configured from the Magic dashboard without requiring additional code updates.

To get started, head to our documentation here. Magic Login Form is compatible with allow list and block list, session management, and other features.

SMS Login

Did I mention SMS login? In October, we released passwordless login support for short message service (SMS). With SMS login, any customer with a mobile phone can use their mobile phone number to login to your web app on a desktop, tablet, or mobile device. To login, the customer will provide their mobile phone number instead of an email or other username and password combination. Next they will receive a one-time code and enter that to complete their login to your application.

SMS login has several advantages including:

• Mobile phones are popular in markets all around the world and can expand your application’s reach.
• SMS login provides a convenient way for your customers to get signed in because it does not require a context change and users often have a mobile phone nearby.
• Returning customers don’t need to remember a password to get signed in. This can improve your customer retention and eliminate your forgotten password support cost.
• SMS login allows you to verify the mobile phone number for each new registered user when they complete login.

To get started, open your Magic dashboard and navigate to Passwordless Login. From there, you can enable SMS in one click. SMS is compatible with the Magic Login Form, web, React Native, and Magic’s Wordpress plugin. Users who sign up on your website will show in your user dashboard. SMS is supported in 38 locales. For more information, see our SMS doc here.

Bitcoin Support

Web 3.0 developers can now connect to the Bitcoin blockchain using Magic. Bitcoin is the world’s most recognizable digital currency and offers a way for developers to connect their decentralized apps (dApps) with mainstream customers. Developers who enable this will be able to onboard new customers easily with Magic’s passwordless user login and a Bitcoin wallet address. Bitcoin is just one of the 18 blockchains Magic currently offers. Head over to our guide to integrate Bitcoin today!

Flutter SDK

We are also excited to share that you can now bring passwordless login to your iOS and Android-based Flutter apps with the new Magic Flutter SDK. Flutter has taken off as an efficient framework for developers to build iOS and Android based apps for both platforms, once. The Magic Flutter SDK speeds up your time to market and gives you flexibility to use popular Social and passwordless logins. To learn more, visit our docs here.

Lastly

Everyone is invited to join us on Discord, where the Magic team and community gathers to chat, as well as help answer questions you might have.

Whether you’re a developer or just keen to join the discussion on auth, decentralized identity, or other modern infra like blockchain — come and say hi!

Magic Product Updates: October Edition was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

It feels so long ago that Magic unveiled its first auth solution in April 2020. JAMstack was having a moment, and so were NFTs. The world had just begun to reckon with shutdowns and social distancing. A surge in remote work showed us that online identity was overdue for a refactor. Centralized infrastructures were being challenged everywhere.

Back then, all it took was one line of code to implement Magic.

We used to hear lots of positive feedback about our whole developer experience. Those docs, you know? So clean.

A year since, the world of web development is again at a threshold. We’re inundated with feedback from users that want a multitude of sign-in options. They want to feel secure, they want to own their data. They desire convenience and seamlessness. Providing an auth experience that serves every user, no matter their technical acumen or accessibility needs, is a costly undertaking for app creators. That’s because building a Magic implementation never really was just one line-of-code. You still have to create buttons, composed into forms, connected to a server. Model user accounts, measure conversion rates, but wait… did I aria-label that button right? Hold on, we need a combobox? Now add social logins to the mix: what the heck is OAuth? Or WebAuthn? This login page is turning into infinite story points!

As we added more and more choices for sign-in, we heard feedback that Magic was harder to use, especially for no-code builders. So, what happened? And why should auth — something that every app needs — be so difficult to build and maintain? That’s a question that’s been bugging me for some time now. I lead the engineering team for developer experience at Magic, so we aimed to set a new standard to help our customers build auth more quickly, more securely, more accessibly, and more user friendly-y.

Occam’s auth

The aha moment came from the simple realization that most modern auth flows follow a discrete pattern: authorization and callback. You prompt a user to authorize themselves, traditionally with an email + password. Or, a more modern (and more secure) approach would use social logins, or Magic’s own passwordless email/SMS flows. Once a user has submitted their proof-of-identity (“authorization”), the app has to then verify this information (“callback”). In the case of social logins, this requires checking a one-time code built around some fancy, math-y cryptographic stuff. Or, using Magic’s passwordless SDKs, you just call getRedirectResult for social logins and loginWithCredential for email/SMS. Building auth for the web essentially boils down to two big function calls. Noticing this, however, presents an opportunity to do what we engineers love to do best: abstract!

But we weren’t going to make just any abstraction.

We want a new paradigm that speaks to the power of web development today and uses web primitives in such a way that the solution can slot into just about any tech stack.

We’re especially excited about no-code and low-code platforms like Webflow and Bubble, so we made it a priority to support those tools as natively as possible.

Introducing (truly) plug & play auth

Today, we’re introducing a new way to implement Magic auth for the web: Magic Login Form.

We think it delivers on the promise of Magic as the easiest, most flexible, and most extensible auth solution available. That’s because we want your frontend implementation to be as simple as copy & paste.

Everything you need to start securely authenticating your users with any of Magic’s sign-in methods is two <script> tags away:

That’s all it takes to connect your app to Magic’s entire suite of auth features. You get a beautiful, accessible login screen with UI best-practices built-in — we’ll even remember which auth method users previously signed-in with. And better yet, your implementation is future-proof and automatically updates with Magic’s service. So, when Magic adds support for your favorite social login provider, you don’t need to deploy an update. Your users will see the latest changes automatically. All of this happens inside of an <iframe> hosted on your domain, so users aren't left questioning what service they're interacting with, reducing the risk of phishing.

At Magic, we think developer experience is user experience.

So we’re trying to remove as many barriers between you and your creativity as possible. With Login Form, you can stop worrying about auth and start focusing on what matters to your users and your business. Though it’s still not quite “one line of code” for everything auth, it’s a hell of a lot closer than we’ve seen anywhere else, and we’re excited about its potential to improve the auth experience for everyone on the web, long into the future.

The first prototype

At Magic, we promote a culture of creative experimentation, and we put this into practice during bi-weekly “demo days.” Everyone on the team has an opportunity to share something they’re working on — whether it’s related to a milestone project, or just a blossoming idea. Some of our best features sparked this way, usually based on pure intuition and user empathy. This takes a lot of introspection as a team. If we’re knowledgable of ourselves, it tends to manifest in great products for our users. So, demo day is also an opportunity for us to invest in each other.

When Login Form made its first appearance at demo day — unplanned and off-the-cuff — it looked like this:

The inspiration for that demo had simmered for a while. When we talked about this “big idea,” to make auth simple and clean and future-proof, it was sandwiched between phrases like “pie-in-the-sky” and “someday…” But, to produce that working proof-of-concept was a matter of hours (it helps, of course, that we already had a universe in which to bake our apple pie).

Demo day was a hit, but that’s only where the real work began.

The “real” work

For the developer experience team, Login Form meant so much more than a pre-packaged UI. It represented a whole new, opinionated implementation approach. Building a login page is pretty easy to “get”, even if you’re not an engineer. We’ve seen a thousand login pages before. But we still had to explain this implementation approach in a way that our product designers and marketing extraordinaries could relate to — we needed to help them tell a story. So, we went back to the drawing board.

It didn’t take long to find consensus on a UX pattern. Again, it’s a login page (a damn good login page). We started with a few design goals:

1. Login Form should be adaptive to a developer’s Magic Dashboard settings, creating a seamless development experience. If you add some Google creds to your Magic account, then Login Form should instantly reflect that.
2. Logging in should be quick, easy, and frictionless — users should never feel lost in sea of sign-in options. So, we want to remember what sign-in method a user has previously used for an app, then we can focus them on the right form automatically.
3. Good design is inclusive design. Our entire login experience should reflect UI best practices and accessibility standards, above and beyond simple compliance.
4. The design should be extensible. While we’re super proud of our initial release, we’re already thinking about ways to make Magic Login Form even better. Simplicity and flexibility help ensure we’ve got room to grow moving forward.

A new onboarding experience for developers

Magic Login Form represents a new onboarding experience for end-users, so we wanted to revamp our own onboarding experience for developers to match. Learning about auth can quickly derail any developer’s good day. Striking the balance between good UX and good security can just boggle the mind. Even building on top of a solution like Magic can quickly spiral into a thousand-thousand esoteric questions. UX tends to be the last box on the auth checklist. So, how do we show-off the “easy button”? We started by looking at our own sign-up experience on Magic Dashboard.

After you’ve completed our passwordless email flow for the first time, you see a screen like this:

When we created npx make-magic, we sought to speed-up development of new projects using Magic. When we added this screen to our sign-up flow, however, we saw a mixed response. Some, especially those from a JAMstack background, were happy to see familiar tooling options. Others were unsure about what npx make-magic was doing in their system, and why they were being asked to start there. One developer was confused upon seeing npx, thinking that Magic worked exclusively for the NodeJS ecosystem—an impression we wanted to correct. The easiest decision for us was to strike this page from our sign-up flow completely.

We replaced this piece of the onboarding puzzle with a new Login Form settings page. From here, developers can access an interactive preview of their customized form. We also introduced a new featured card to Magic Dashboard’s home page, surfacing this new implementation approach with a beautiful, eye-catching design.

Now what?

Getting started with Magic Login Form is super easy. Log into your Magic Dashboard account and go to Login Form. Try a demo for your very own plug & play login page. You’ll also see a link to download a working implementation using your actual API keys!

We’ve also written some documentation to help you build a plug & play login experience from the ground up. And, of course, we have added a template to our CLI scaffolding tool to generate a working implementation in under a minute. Simply run the following command in your preferred shell:

npx make-magic --template plug-and-play

So long, and thanks for all the fish!

We hope you enjoyed this peek behind-the-curtain of the all-new Magic Login Form (fun fact: our internal code name was “Auth-in-a-box”). By the way, it’s totally free to try. If you’re interested in getting more involved, join the Magic Discord server, where you can provide feedback or connect with a vibrant community of developers.

And one more thing: we’re hiring!

Building a low-code, opinionated approach to plug & play login was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

Phones are ubiquitous; the largest segment of the world’s computing base. However, despite significant market adoption of a few operating systems, interoperable standards for messaging are rare, and often segmented.

SMS (Short Message Service) messaging¹, despite a number of material challenges, has broad adoption, international regulations, and support across platforms.

This post details the use of SMS as an authentication mechanism.

What is a high quality SMS login system?

• Easy for Users, Hard for Attackers
• Works globally, across all cellular carriers, even in lossy service environments.
• Enrollment, opting out, and authentication are beautiful, simple processes.
• Confidence the user has access to their phone, and the phone number is valid.
• When users change their phone number, they don’t stop using the service; they can migrate to a new phone number smoothly.
• When an attacker pretends to be a user, they are prevented from taking over the account.
• A user should not be easily duped into helping their attackers.

SMS can be temporarily undeliverable

SMS delivery is not guaranteed, and many implementations provide no mechanism through which a sender can determine whether an SMS message has been delivered.

💡 Allow users to request a new code as part of the product. Use a different code for each message.

SMS can be permanently undeliverable

Users can request to stop receiving SMS from a particular sender, often by replying with ‘STOP’. Users will no longer receive messages.

In the United States, FCC affirms text messages are covered under the “Telephone Consumer Protection Act”, and users have a variety of rights, including to Opt-Out.

💡 Notify users when their phone number is undeliverable: either in-app, or via email

Messages can come from unfamiliar sources

SMS standards make spoofing phone numbers difficult. However, no easy way exists for consumers to authenticate numbers or associate them with businesses. Messages appear with only a number to identify them.

Users are habituated to ignore sender ids, or react with suspicion when numbers are changed.

💡 Include information about the sender in your message “Your ACME.co Code: 123–123”, or use Domain-Bound Codes

Users can be on fraudulent sites

Some sites trick users into entering authenticator codes for other sites. A common ploy asks for a user’s phone number, and prompts the user to enter the code they receive. The attacker simply forwards the collected code to the target, and successfully poses as the end user.

1. User Logs in to Fraud Site. Provides User phone number
2. Fraud Site forwards request to Real Site
3. Real Site sends User a SMS challenge. However, User thinks it comes from the Fraud Site
4. User enters correct SMS onto Fraud Site
5. Fraud Site / Attacker uses correct SMS to log into legitimate site
6. Attacker now has legitimate session on real site

💡 Include information about the sender in your message
Your ACME.co Code: 123–123 or use Domain-Bound Codes

💡 Monitor for automations and headless browsers attempting your site’s login flow

Users can change their phone number

Users, particularly those outside of the United States, change their phone numbers often, giving rise to the popularity of messaging applications.

💡 Facilitate self-service recovery of SMS logins through alternative channels

Attackers request control over phone numbers

SIM-swapping attacks are social engineered takeovers of a user’s telecom contract. Calling customer support and transferring phone numbers between phones is common practice for consumers, and is exploited by attackers to capture SMS messages.

Users can, though rarely, defend themselves, and unfortunately many users remain susceptible to these risks.

💡 Many SMS vendors provide carrier information in their API responses. If the carrier changes for a given number, send a confirmation email.

Domain bound codes, an emerging solution

The emerging standard for SMS security is to use Domain-Bound Codes for authenticating and protecting SMS messages.

Messages are formatted to describe their sender, and allow automated tools to read those messages to auto-fill or protect users.

Major mobile operating systems support or plan to support domain-bound codes.

123-456 is your ACME.co code.
@acme.co #123-456

Enhance SMS-delivered code security with domain-bound codes — Apple Developer

Providing a good SMS user experience

SMS login flows can be complex to build and manage, but a few considerations will make the experience as smooth as possible for your users.

Allow users to copy-paste into your SMS input box

• Diverse interfaces exist for mobile devices, and users may not type in codes using a keyboard. Allowing paste makes your service more accessible, and a smoother end user experience.

Using numeric codes? Label your input box as `numeric`

• Phone soft keyboards use information about the input box to render the most usable keyboard for the use case. Showing a numeric keypad helps make entering codes as easy as possible

Supporting iOS users? Tag login boxes with textContentType

• Operating systems such as iOS make it easy to fill in one time codes from SMS messages. Apple uses a text content tag of textContentType=.oneTimeCode to allow users to auto-fill new SMS codes into the page.

Building with Google Play? Consider auto-verification with the SMS Retriever API

• Android’s Google Play Services offer a collection of advanced SMS tools for verification of SMS codes, including supporting background verification.
• With the SMS Retriever API, It is possible to build almost silent user and device verification, however, fallback support for traditional SMS is required, and informing users about what is occurring is critical for building user trust and comfort.

Building Web Applications? Use `autocomplete="one-time-code"`

• Many browsers facilitate SMS message autofill through input code tags for autofill, such as autocomplete="one-time-code". This can provide smooth user experiences cross-platform, and allow your product to take advantage of built-in browser functionality.

Using Magic for SMS authentication

With challenges ranging from usability, deliverability, internationalization, fraud, bots, social engineering, and multi-device support, the simple user experience of SMS login comes with complexity for developers.

Magic makes authentication easy for you and your users. Supporting a broad array of use-cases with a beautifully designed developer experience, getting started with SMS login is easier than ever.

Learn more about SMS Login and Magic

Join Magic’s Discord: https://discord.com/invite/magiclabs

Follow Magic on Twitter: https://twitter.com/magic_labs

¹Note: the terms ‘SMS’, ‘message’, and ‘text’ are used colloquially to refer to ‘Short Message Service messages’

Building SMS Authentication is Challenging was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, I’ll cover a round-up of the most recent product updates.

Allow List and Block List

Last month, we released Allow List and Block List, an access control feature that helps you easily manage who is and isn’t allowed to log in to your app from the ease of your Magic Dashboard. No code is needed.

Access can be gated in two ways: explicitly allowing only certain emails and domains through with Allow List, or blocking certain emails and domains with Block List. For example, you can specify a unique email address like email@magic.link. Alternatively, you can use a domain wildcard like *@magic.link for additional flexibility. Up to 20,000 specific email addresses or domains to be added to your Allow List or Block List.

We’ve heard from our customers that this capability comes in handy for many use cases. Some of the most popular we heard include:

• Rolling out a private beta for your app
• Managing access for a gated community
• Working on a membership-based app or service

To get started, head to the Settings tab to toggle on an Allow List or Block List.

Customizable Sessions

Now with Magic, we have made it easy for you to customize your user’s session length all without the need to write an additional line of code. Our new refresh token persists without requiring your users to re-authenticate for up to 90 days. Not only this, the refresh token works with privacy browsers and browsers with 3rd party cookies disabled, providing a persistent session for your users.

From the Magic dashboard, navigate to Session Management under your app Settings page and toggle on Auto Refresh. You have the flexibility to pick session lengths ranging between 7 days and 90 days. The feature is available for email and all social login methods.

Microsoft and Twitch OAuth Support

We’ve expanded our list of federated social login providers to include Microsoft and Twitch. These providers allow your users to register or sign in using Microsoft or Twitch to your app. The Magic client SDKs are available in Javascript, React, and mobile platforms iOS and Android.

✨Magic Community

Beyond new features and capabilities aimed at making the developer and end-user experience better, we are also focused on supporting the Magic community (that’s you!). It’s simple: we 💜 to connect, share, and learn together with developers around the world.

👋Join us on Discord!

Everyone is invited to join us on Discord, where the Magic team and community gathers to chat, as well as help answer questions you might have.

Whether you’re a developer or just keen to join the discussion on auth, decentralized identity, or other modern infra like blockchain — come and say hi!

One of our community members, dng from London, asked an excellent question:

Here’s how you can contribute and make the most out of the community:

• Share product feedback directly with the Magic team
• Become a Guest Author to teach members through tutorials and blogs
• Talk about your favorite tech at Close-up Magic meetups as a special guest
• Connect with other members in a monthly Community Call
• Celebrate wins together

We would love to have you with us on this journey and can’t wait to see what you build with Magic.

Magic Product Updates: September Edition was originally published in Magic on Medium, where people are continuing the conversation by highlighting and responding to this story.