Authentication with Magic Link

Did anyone try to use Magic link for authentication instead of Moralis authentication service along with other Moralis services. As it also gives some key management functionality which can be easily used for mobile application to sign transactions without metamask.

Hey @SaicharanPogul

Moralis has native support for WalletConnect. And it supports a huge number of wallets. If your task is to integrate the possibility of authorization via mobile wallet and without extra code, this is the solution for you WalletConnect Docs

Thank you @Yomoo for replying.

Yes, but WalletConnect can affect UX as users have to navigate to wallet for signing transactions. Especially for mobile DApps users it can be very cumbersome task. Magic link offers a good option to signup/login just with email (passwordless) and also offer signing transactions within app.

If you don’t need to sign transactions using magic, does it mean that they store your private key somewhere? (it’s a question)

Moralis also supports non-crypto authorization. But for the safety of users, every transaction must be signed, and this is the industry standard.

This is from Magic’s white paper -

Magic is a plug-and-play SDK that supports a variety of passwordless login methods, including email magic links, WebAuthn, and social login - Facebook, Google, Twitter, LinkedIn, Discord, and more. With enterprise-grade security and reliability -global availability, 99% uptime, SOC 2, 3rd party testing, SLAS certified compliant with the latest standards - Magic gives companies peace of mind as their apps scale, all with just a few lines of code. Powered by blockchain technology, Magic helps companies outsource authentication and save on headcount for a dedicated security and fraud team.

Delegated Key Management

This public-private key approach means that the user’s identity is eectively bound to their private keys. Therefore, it is critical to ensure that users’ private keys are properly secured. Traditional databases are susceptible to data-extration attacks, which has prompted the development of our own proprietary Delegated Key Management (pat. pend. USPTO 62/904689) System.

Hardware Security Modules

Magic’s Delegated Key Management leverages Hardware Security Modules (HSMs) provided by Amazon Web Services’ Key Management Service (AWS KMS). Dedicated user master keys generated using AES-256 with 384-bits of entropy are stored on the HSMs. The master keys never leave the hardware as they are meant to be locked inside and unable to be exported. All encryption and decryption operations happen inside the hardware modules themselves. HSMs are a lot like popular FIDO devices like YubiKeys or hardware-based wallets for cryptocurrency storage such as Trezor or Ledger, but instead of traditional harddrive storage, they sit in the cloud, secured by AWS’s data centers. Users’ private keys are encrypted by these hardware-based user master keys, which means that attackers need to gain access to the hardware to be able to retrieve the keys, and are forced to stay within Magic’s adversarial infrastructure - which is capable to detect, impede, and monitor attacker’s progress to prevent and mitigate any damages.

Non-Custodial Trust Optimization

Magic’s Key Management architecture delegates critical encryption and decryption operations to a trusted AWS KMS and AWS Cognito - completely bypassing the Magic backend. This lets Magic stay non-custodial (standard for trust amongst crypto communities) as user private keys are never seen by Magic’s systems.

Client to AWS Data Flow

For users to access their HSMs, they authenticate with the Magic auth relayer. Upon successful authentication, users receive a time-bound access token, which is traded for scoped credentials, and in turn, allows the client to interact with AWS directly. The scoped credentials exclusively enable users to call the AWS to access their master keys stored on the HSM for encryption and decryption. This mechanism bypasses the Magic backend entirely, and Magic cannot forge nor intercept the scoped credentials because they are generated by the operations exclusively between the clients and AWS. Both access tokens and scoped credentials are created dynamically by AWS, with audit logs, and with TTLs enabled.

When a user signs up, a public-private key-pair is generated on the client-side for the user inside a javascript browser iframe, inaccessible by the integrating app. Keys are generated with cryptographically secure pseudo-random 256-bit entropy. Once generated, the key is encrypted by the Delegated Key Management System, where no parts of the raw private key are seen by the Magic infrastructure. After encryption, the encrypted key is stored on the client-side iframe as well as uploaded to the Magic auth relayer for redundancy, in case the encrypted key on the client-side is accidentally removed. To ensure Magic cannot decrypt the encrypted key for redundancy, we have removed our permission to decrypt with our KMS instances. When users authenticate again, the encrypted private key is downloaded to the client. Users can then decrypt the encrypted key directly with AWS KMS via Cognito.

Passwordless Authentication

Magic users do not set/memorize passwords for authentication. Instead, a Magic Link email is sent to the user’s mailbox. The Delegated Key Management credentials are loaded onto the client iframe after the Magic Link is clicked. This way, Magic eliminates the case where users can be phished for account passwords. Moreover, if a magic link email is lost or stolen (or even somehow compromised in transit), a user’s account remains safe. The token included in the magic link email is only privileged to verify a login request from the device and/or browsing context that initiated the request. An attacker would require physical access to the user’s device and an unencrypted email inbox to be malicious.

1 Like

Thank you for the info.

Integration of such a tool can be quite complicated, but we have a tutorial. If you come across a specific problem - feel free to ask questions

Maybe adding Magic link as a plugin in Moralis can be more beneficial as it offers secure authentication.

1 Like

Plugin creation functionality will be available soon. So this is really a good idea for a future plugin.

Right now, if you want to use magic, you need to integrate it yourself. If you come across a specific problem - feel free to ask questions :man_mechanic:

I’m not sure I completely get what Magic link does, it can use you wallet private key to sign transactions or not? As in you’ll have to upload your wallet private key to their servers or not?

Yeah i will give it a try and add the updates here. Thank You @Yomoo

Hi @cryptokid, the actual user’s master keys are stored in HSM. The below info from the white paper clearly explains how Magic works with keys.

Hi @Yomoo, is there any way i can override the Moralis.Web3.authenticate() as the actual functionality of it is to authenticate with the wallet and store the address in the moralis user object. This is how address is retrieved from magic. I need to modify the authenticate() function to get address from magic which is after successful authentication by providing email so authenticate() function also has to accept a email parameter.

const web3 = new Web3(magic.rpcProvider);

// ⭐️ After user is successfully authenticated

// Get user's Ethereum public address
const address = (await web3.eth.getAccounts())[0];

Hi @SaicharanPogul, did you ever get a working example with Magic? I’m currently using WalletConnect to sign into an existing wallet, which works, but is a pretty clunky user experience and doesn’t allow new users who don’t already have a crypto wallet. Ideally for a new user I’d create a new wallet, and then log them in using Moralis.