Magic

Make passwords disappear with a touch of Magic

5.0•1 review•

166 followers

Make passwords disappear with a touch of Magic

5.0•1 review•

166 followers

Visit website

Authentication & identity tools

Passwords are the bane of app security. With a few lines of code and no bloat, Magic lets you build apps with blazing-fast, customizable, passwordless login - with future-proof crypto and identity tech under the hood.

Launch tags:API•User Experience•Privacy

Launch Team

Atlassian LoomShow, don't just tell with Loom

Promoted

Zelos

What's the difference between Magic and a product like Fast? Regardless, the integration is super seamless... Wow

Report

6yr ago

Magic

Maker

@trigun0x2 Thanks so much Jeff! Fast is focused on e-commerce companies with a streamlined checkout experience, while Magic is focused on providing a robust identity service that can be used for both startups and enterprise companies (SOC 2 compliant). The other major difference is that Fast in this case is a centralized identity provider with a SSO-like experience, which also means that developers will have to expose the Fast brand on top of their own UX (like Facebook or Google auth). Magic instead gives users decentralized identity which is self-sovereign without having to trust centralized identity providers. Magic also gives developers the ability to customize the magic link experience, giving them a lot more control over the UX! A cool secret with Magic is that every single user will be issued a blockchain key pair, which means for advanced developers, they'll be able to easily tap into the power of blockchain and cryptocurrency to build future-proof and innovative applications!

Report

6yr ago

@trigun0x2 @_seanli When you say "without having to trust centralized identity providers", aren't you still trusting AWS? Afaiu, they hold all users' private keys in clear.

Report

6yr ago

@trigun0x2 @_seanli @paul_mckenzie I think that's a choice for developer. like their is a concept of User Agent (It could be mobile device or a cloud) . It depends on security vs Usability what devs want more

Report

6yr ago

Your "Security" section is a great read in and of itself. Thanks for this product. How common is the "passwordless" approach at the moment?

Report

6yr ago

Magic

Maker

@devishnya1 Thanks!! We are very optimistic that it's a matter of time before passwordless auth start to catch on in mainstream applications! It's already been used as a predominant form of login for companies like Slack, Medium and Substack, with great results in terms of security and conversion, and we are in conversation with many more companies ranging from startups to enterprises who wants to switch over to Magic links! Passwords introduce so much overhead and risks these days giving the current cybersecurity climate and increasing number of data breaches. There are many caveats and challenges for developers to roll their own magic link, but that's what we are trying to make easier with Magic! We will provide not only just magic link login, but other form-factors like WebAuthn and mobile authenticator apps - passwordless login is looking to surpass password login as a predominant form of login within 10 years!

Report

6yr ago

Memo

@devishnya1 it's certainly growing in popularity we launched our own solution on producthunt this month https://www.producthunt.com/post... and are excited to see more people in the space.

Report

6yr ago

Looks really interesting. Passwords can be a real access barrier for many people with cognitive and learning disbaiities. However I'm concerned about how this will work when you do NOT have access to email? I know this is seen as very unlikely but it's not impossible. For example might be in a private session on unknown computer without phone and extra hasslie of signing into web mail not wanted. Or just left your phone somewhere out of reach. Or just using someone else's device. How does this mesh with offline and PWAs - that problem is probably out of scope for you but interested to know.

Report

6yr ago

> The cool thing with using decentralized identity (DID) is that developers only need to deal with DID tokens signed by keys on the backend, and the front-end key management form-factor can be very flexible without having to change the backend code! That probably answers my last Q :) Is it safe to store token in local storage as some OAUTH / OPENID solutions do?

Report

6yr ago

Magic

Maker

@stevealee Thanks for the great questions Steve! - The magic link for now will piggyback users' email provider's recovery mechanism - In the near future we will have other hardware/device login which can be added by users for added security and recoverability! Progressive disclosure is key for Magic, ease users in with magic links, and then graduate them into more advanced ways to login - Definitely looking to be able to support offline and PWAs, as well as native mobile applications (coming soon) - If you are referring to the DID token, under the storage associated to your domain, it will be up to your web app's security strength. With proper web security configuration (e.g. CSP) and watching out for the top 10 OWASP vulnerabilities like XSS, it will be safe to store it in the localstorage. In our documentation we've showed some example on how a replay attack can be prevented as well!

Report

6yr ago

@_seanli soooo if a user has Yubi or biometric tha tworks on the device receiving emails? Also emails are not guarenteed delivery times (or even a tall) Are there any fall backs. I'm not criticising, just try to understand the edge cases. I'm basically excited like Elliot.

Report

6yr ago

Magic

Maker

@stevealee: Thanks for the questions! Happy to take a stab at this one :) > Is it safe to store token in local storage as some OAUTH / OPENID solutions do? It is definitely very true that many things come into play to determine if it is safe to store data on the client side. It largely depends on what information a token is bearing and the current security strength of the web applications. The rule of thumb is always to avoid storing any sensitive information on the client side and handling it on the server side. OAuth's access token is a good example of a token that should be handled on the server side. The token itself has been authorized for some scopes, and it can be used to modify or retrieve user info from the OAuth providers. If this token is stolen without notice, the sensitive information can be altered and leaked. As for the OpenID Connect, since the protocol wraps OAuth to provide the identity layer that OAuth doesn't support (it is a common misconception in the ecosystem that people misuse/abuse OAuth as the identity where it should only be used as a resource authorization scheme), it provides both ID token and access token. The access token here is the same as the OAuth's, and by the best practice, it is strongly recommended to handle the access tokens on the server side. As for the new ID token, it is used to provide web applications with user info from Identity providers, serving like a client side caching layer with a TTL (token expiry). It is not indented to be used to gain access to act on behave of the users. if an ID token carries a field like `nick_name` (besides all the required fields), I would actually consider that it is safe to be stored on the client side. Having this data in the LocalStorage can improve the overall user experience because the application doesn't need to make another network call to retrieve `nick_name` when it needs to show the user profile page. It can read the info directly from the ID token. If the tokens expire, users will just have to re-authenticate again. Provided with the right balance and the intent of the token, it can be helpful to determine if it is safe to store on the client side. Even though server side handling is always recommended, developers still have the ultimate control. The application security posture will then become super important :).

Report

6yr ago

@arthur_jen ooh so no refresh tokens with Magic!? \0/ \0/

Report

6yr ago

I must say Magic passwordless login is really cool. One question I have is: why does it direct me back to the original page when I click the magic link?

Report

6yr ago

Magic

Maker

@alex_kim4 Thanks so much! It's awesome that you noticed it and asked, we log users into the "original context" after the magic link is clicked, and we do this for several reasons: * Taking modern user behaviors into account with users going between laptop and phone. Users are gravitating more towards their phone. Generally with web applications like Medium, users are logged into the tab where the magic link is clicked, but this may be a problem when users clicked on the link on their phone and is logged with the phone rather than the laptop, making editing very inconvenient. With Magic's model we can get through complications with Incognito mode too. (Though we will be exploring deep linking with our mobile SDKs) * If the magic link URL get hijacked somehow, the hackers will only be able to login users into their original tab, which can mitigate damages. * Training user behavior to gradually shift to user an authenticator app like DUO on their phone by subtly encouraging users to use both laptop and phone to authenticate

Report

6yr ago

@_seanli I see. I was able to figure out that I had to go back to the original tab. For non tech-savvy users that may not be able to figure this out, how are you planning on improving your UX to make sure they know / learn that they need to use their original tab? I remember the error showed "magic link expired", not "You closed your original tab, try again" P.S. I really like how you guys are tackling passwordless login from UX and security point of view.

Report

6yr ago

Memo

@alex_kim4 I'd be really interested to see how this turns out. At did.app we used to direct users back to the original tab, we even tried using alerts to pull the focus. In the end though we moved away from it because non-technical users kept getting frustrated. Like I said tho interesting to see if they can polish the UX

Report

6yr ago

Submarine.me

@_SeanLi another awesome product! Congrats on the launch. I know Fortmatic recently introduced a pricing model. Do you have a plan around pricing for Magic?

Report

6yr ago

Magic

Maker

@jehunter5811 Thanks Justin!! The pricing model will actually be quite similar to the Fortmatic pricing model. We are finalizing the details and eventually the goal is to fold Fortmatic whitelabel SDK users into Magic, and the free base plan is going to also be in Magic!

Report

6yr ago

Hey Sean, very cool product. Quick question - if we already have password based log in, how does Magic integrate with that? Or does it only work if you're launching a new project going forward and you choose to eschew passwords completely from the beginning?

Report

6yr ago

Magic

Maker

@duncan_cock_foster1 That's a very good question Duncan! We designed Magic to be able to integrate seamlessly with existing applications too and not just for new projects. You should be able to plug Magic into your existing session management (if there's any) and get rid of passwords by only requiring user magic links. You can take a look at the following tutorials for how that can be done: Express + PassportJS: https://docs.magic.link/tutorial... Firebase Auth: https://docs.magic.link/tutorial...

Report

6yr ago

@_seanli can it work along side passwords? for example, could we present users with the ability to log in with a password, and then also use magic if they would like to do so?

Report

6yr ago

@_seanli @duncan_cock_foster1 I think the technical answer to that is yes, but passwords come with very serious security, privacy, and financial risk hazards for your users due to the risk of password database theft. I've covered this topic in depth in many other places so I won't go too deep here, but the short version is there is no really safe way to store passwords, even hashed, salted, peppered passwords, and most users reuse the same passwords on multiple sites. That means providing a password option on your site could be endangering your user's bank account, or medical records, or identity, and that could open you up to liability you don't want. Passwords are obsolete.

Report

6yr ago

Great to see that you all will be integrating with Zeit / Next.js! Any timeline on those projects? Congrats on the launch--product looks incredible

Report

6yr ago

Magic

Maker

@ggarnhart Thanks Greg!! Zeit/Next.js will be one of our next examples! 😉We've already started writing the example code for this, but couldn't make it for this launch :p I'll be jumping back to it after this launch and am looking to get this out in a couple weeks! Also feel free to suggestion other examples we should write too!

Report

6yr ago

@_seanli Awesome to hear! The express example is the one I'm looking at now, but I'd love to see this work in other apps. Might be neat to do something with Flutter 😮(i'd peg that at a far lower priority, as far as my needs go, though!) Thanks for building cool things :)

Report

6yr ago

Magic

Maker

@ggarnhart Thanks for the suggestions - love making fun toys for developers! Flutter is an interesting suggestion - I can talk to my team about it. Though RN, iOS and Android native SDKs should be coming soon 😄

Report

6yr ago

1 2 3

•••

5.0

Based on 1 review

Review Magic?

Magic is praised for its seamless integration and ease of use, making it a versatile solution for various business needs. Users appreciate its tailored functionalities, which allow for high personalization across industries. The passwordless login feature is highlighted for its speed and customization, enhancing user experience. Additionally, Magic's pricing model is considered favorable, especially for startups. Overall, it is well-received for its ability to simplify app security without compromising on performance or future-proofing.

Summarized with AI

Reviews

Most Informative

Magic

Make passwords disappear with a touch of Magic

Make passwords disappear with a touch of Magic

What's great

What's great