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 
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?
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.