#General

#Can the magic link redirect to a specific URL?

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.

#Can I delete users from the dashboard?

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.

#How can I service GDPR deletion requests from my users?

Magic offers a Deletion Request API that enables developers to delete users' information in compliance with GDPR.

#How do I restrict which Domains have access to my API key? 

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:

• http://localhost
• https://example.com
• https://*.example.com
• http://example.com:8080⁠

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.

#Can Magic serve as my database?

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 email, 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.

#Can I link email addresses and social logins?

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.

#Can we separate the login and signup?

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.

#How can I migrate off Magic?

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.

#Questions Around Email

#What to do if emails are delayed

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 noreply@trymagic.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 noreply@trymagic.com email domain to their internal allowlist should prevent emails from being held up by the spam filters.

#What if a user loses access to their email?

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.

#What if someone tries to phish users with a fraudulent magic link email?

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.

#Is there a way to add custom text to the magic link email?

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.

#Questions Around SMS

#Is my country code supported?

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.

Currently blocked country codes:

#Sessions and Tokens

#How long does a user remain logged in?

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.

#Session vs DID token?

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 true or false.

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

#What is the unique user ID I should save to my database?

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

#Are DID tokens invalidated when a user logs out?

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.

#Refresh Token Security

#Securing the Magic refresh token

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.

#Blockchains

#Why is my custom node configuration not working due to CSP errors?

💡You can allowlist a custom RPC URL for Dedicated apps by adding it to the app's Content Security Policy in the app settings.

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 reach out via our help widget If your app uses Universal wallets and you see errors similar to the following:

#How can I allow users to view and export their private key?

Developers can now call the revealPrivateKey method to initaite the private key reveal flow within their apps. Users no longer need to leave your app to get their private keys! This method is available on our Web, React Native, and Android SDKs. If your app is not able to use this method please continue reading about how you may request a private key reveal page.

For applications that aren't able to call the reveal private key method, ⁠Magic creates a private key reveal page for your users to log into using the same login methods as your app. This page is only made for your app upon request. When the user logs in they will follow intuitive prompts to reveal their private key. If you would like your users to be able to view and export their private key, please contact us using the chat widget in the bottom-right corner of this page with the following information:

• Your API key (starts with pk_live)

• A list of blockchains you are using

• Your app name for the endpoint, such as https://reveal.magic.link/your-app-name

The login methods available on your reveal page will match the login methods that you have activated in your Magic developer dashboard (found under "Passwordless Login" and "Social Login"). Please make sure to deactivate any login methods that you are not using. Login methods can be added and removed at any point and changes will be immediately visible on your reveal page.

The look of the UI for your reveal page will also match the settings configured within the "branding" section of your developer dashboard. This includes the logo shown, the primary color, as well as choosing between light/dark mode. More details on branding and UI customization can be found here.

#How can I make changes to my legacy private key reveal page?

If you have an existing private key reveal page hosted by Magic and need to make changes, please reach out via our support widget in the bottom-right corner of this page.

#App Store Review

#How do I provide the reviewer with a test account?

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 `name+test@company.com` and click the link when triggered by the reviewer to log them in.