Frequently Asked Questions | Magic

Frequently Asked Questions | Magic

note

Have a question that isn't answered here? Reach out to support@magic.link.

General

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.

Can I export users from the dashboard?

This is not yet supported but will be down the road!

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.

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

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.

Sessions and Tokens

How long does a user remain logged in?

Users remain authenticated with the Magic service for up to 7 days (or until they clear their browser history/caches). This means that a user will need to click on a magic link, at most, once every 7 days for each device they log into. We are exploring ways to allow this session length to be customizable via SDKs or the Magic Dashboard.

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 is valid for one year, the session set by Magic is still only valid for 7 days. 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.

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.