Frequently Asked Questions
Frequently Asked Questions
Yes! When calling the
loginWithMagicLink sdk method you can pass in an optional
redirectURI value which specifies the URL to redirect your user back to once the magic link is clicked. If no redirect is specified, the user will see a confirmation screen telling them to go back to the original tab where they will be logged in. We recommend this for an improved UX flow.
We don't support deleting users from your dashboard view. However if you are requesting to delete any PII user data on behalf of the user we can absolutely process those requests.
This is not yet supported but will be down the road!
Magic developers can specify which domains are allowed to use their application's publishable API key by configuring Domain & Mobile Access Whitelisting from the Settings page within the Magic Dashboard. The Domain & Mobile Access Whitelisting configuration is disabled by default for all newly created apps. Only the domains you specify will be accessible by your application when enabled.
To configure domain access, open your application's Settings Page from the Magic Dashboard. From there, you can Edit the list of domains you want to support. Specific domains and wildcards using * are supported. Examples are below:
There is no need to whitelist domains required to complete any Social Login (i.e., https://accounts.google.com, https://facebook.com, etc.) or Private Key Export (i.e., https://reveal.magic.link) flow. Magic automatically accepts these domains and any other domains on your whitelist.
Magic is not meant to replace your database, so if you need to store any information about users, you'll manage your own DB. We also won't store any custom user data, (only
public address and
issuer) but that doesn't stop you from prompting users for more info (such as first name, last name, etc) and storing that in your database. Magic also does not support importing user data.
Currently, when a user logs in through email and then through a social login, those are counted as two separate users (each will be given a unique ID) even if using the same email.
Absolutely. The Magic code to power the authentication will be the same regardless of if it's a first time user signing up or a returning user logging in. However if you want to prompt new users for additional information to store in your database such as name or address, you can have a separate login and register page. To check if a user is new, you can simply query your database for the email before calling
loginWithMagicLink and if the email doesn't exist you know it's a first time user and redirect them to the register page.
Magic comes with essentially no vendor lock-in, so migrating away is easy. You will have the user's unique ID (
issuer) and email both stored in your database (and any other user info) so are free to choose another service or move authentication in-house should you want to do that.
Rarely, a user may not receive a magic link email immediately after requesting one. This is usually due to a spam filter holding onto the email before eventually displaying it in the user's inbox. If it's a personal email, adding our sending domain email@example.com to their email contacts list should solve the problem. If it's a corporate email, asking the user to have their IT team add our firstname.lastname@example.org email domain to their internal allowlist should prevent emails from being held up by the spam filters.
If a user loses access to their email account, they need to contact their email service provider (i.e.: Gmail, Microsoft Outlook, iCloud Mail) and follow steps for account recovery.
Phishing attacks are an ongoing problem that exists in our industry today. However, this doesn't mean we are sticking to the status quo; we are actively working on ways to mitigate this. We have minimized the attack vectors significantly by going passwordless—no credentials are passed around! Compared to traditional password-based solutions, Magic eliminates the case where users can be phished for compromising account information.
Plus, if a magic link email is lost or stolen (or even somehow compromised in transit), a user's account is 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 unencrypted email inbox to be malicious.
However, a motivated attacker could create an identical replica of your application, which is a known phishing pattern that occurs today. For this case, we recommend developers to whitelist specific domains for their Publishable API Keys on the Magic Dashboard so that illegitimate applications cannot forge requests through the Magic SDKs.
Right now there isn't a way, but we will soon implement a feature that enables developers to be able to completely customize the magic link email, and that will include being able to add your company-specific Terms of Service.
Some country codes are blocked due to heavy spam traffic from the region. If a user's country code is blocked they may still authenticate through email.
Below is a list of currently blocked country codes:
+7, +45, +53, +62, +92, +94, +98, +225, +231, +243, +244, +249, +263, +291, +370, +375, +591, +670, +855, +870, +880, +881, +882, +883, +962, +963, +964, +968, +994, +996
By default, users remain authenticated with Magic for up to 7 days (or until they logout or browser data is cleared). Developers can enable and configure auto refresh sessions in our developer dashboard, extending the session up to 90 days instead of 7. See Session Management for more.
If you're building a custom backend, we recommend our Decentralized ID token as a way to initiate server-side sessions. The DID Token is a cryptographically-generated proof of user authentication. Your resource server simply needs to validate the token and set an HTTPS session cookie. This option gives you the flexibility of maintaining your own sessions without storing user secrets.
The session (how long a user is logged in for) is set by Magic through cookies/browser storage. Client-side, you can tell if a user has a valid session by calling
magic.user.isLoggedIn which will return
DID token is proof of authentication, not necessarily proof of having a valid session. That's because the
getIdToken sdk method can create a token that expires far in the future, and just because a token was theoretically created with an expiration for one year in the future, the session set by Magic may not still be valid. The DID token that's returned from
loginWithMagicLink has a default lifespan of 15 minutes and is generally used to send to the server after login to validate its authenticity with the admin sdk
validate function. The
DID token can be used to access a protected API route on the server if stored in a cookie or client-side storage. You can create a token with
getIdToken any time a user is logged in.
Developers can control how long the Magic session lasts in the developer dashboard.
issuer is the unique ID provided by Magic for each user. The
DID token shouldn't ever be used as the unique ID because for each user, and each login, the token is unique. When decoded, it contains information about the login, including a timestamp.
When a user logs out, the session will expire but a previously generated DID token is not automatically invalidated. The only way for a once-valid DID token to be invalidated is for it to expire. That's why it's best to create short-lasting DID tokens when the user is logged in and re-generate them as needed (if needed) by your application.
While the Auto Refresh sessions feature is enabled, Magic will use the browser's IndexDB to store refresh tokens under your domain. These refresh tokens can be exchanged for a Magic session. If your application is vulnerable to Cross-Site Scripting (XSS), it is not within Magic's control how an attacker will exfiltrate these refresh tokens. We strongly recommend that you review OWASP's documentation on XSS vulnerabilities. OWASP also provides a great starter sheet for XSS prevention.
If you are a Web 3 developer, we strongly encourage you in particular to understand your application's exposure to XSS. A successful XSS attack targeting a Magic refresh token on your application could translate to the attacker owning your end user's Web 3 address/wallet.
Magic provides robust blockchain support, including the ability to emit requests directly to your own, custom node infrastructure. To maintain a high-level of security, we require that customers' coordinate with our support team to allow the domain of your specific node provider to work within our
<iframe>. Please contact email@example.com if you see errors similar to the following:
You can create a test email account and provide the login credentials on submission. The reviewer can authenticate by logging into the test email account and clicking the link or getting the OTP code.
Alternatively, you could provide the reviewer with a test email address you already own, such as `firstname.lastname@example.org` and click the link when triggered by the reviewer to log them in.