@jpamorgan Thanks so much for the help testing and the feedback John! We're aware of the potential phishing risks like you described, and will be releasing the feature to detect where and how the user has opened the magic link in order to prevent users from accidentally clicking on a malicious login attempt! There's only so much that can be done in terms of email security. In the future, through progressive disclosure, we'll be gradually introducing users to more sophisticated form-factors of login we are working on like WebAuthn / mobile authenticator apps.

@the_minh Thanks! The main difference is that Auth0 is a centralized identity provider, similar to Facebook or Google. But Magic uses decentralized identity (https://w3c-ccg.github.io/did-pr...) using blockchain-based keypairs, meaning that user identity is self-sovereign and portable (no lock-in, more ownership). We also have a whitepaper about our architecture as well: http://go.magic.link/whitepaper/ Our business model is a SaaS subscription model based on the # of keys/users being managed by an application. Pricing page will be coming live soon!

@danielque Thanks Daniel! Hahah that's such a throwback, they are definitely ahead of the curve! Lots of great shifts in user behavior have been happening, as well as improvements to identity tech. The world of auth is about to get interesting again! ✨

@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!

@meakaakka Thanks Akash! Magic link relies on the users' security of their email. It's a good place to help users get started, the goal here is progressive disclosure, eventually graduate users towards more sophisticated device based login via WebAuthn / our own mobile authenticator app

@_seanli got it. The challenge here is to let users get familiar with the magic link flow. And I think a mobile authenticator app would surely fix this security issue.

@ianissoawesome Thank you so much for the kind words and great feedback Ian!! 💜

@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!

@_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 :)

@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 😄

@sergey_lukin Thanks so much Sergey! Pricing page is coming very soon! We'll be charging a base fee a fixed charge per active user per month. We'll be carrying over the pricing from our existing key management product (https://fortmatic.com/pricing) and make slight adjustments. Love to hear your feedback on the price range as we are trying to make this an optimal choice for startups and growing companies too!

@lyondhur No need to apologize and thank you for your transparency! We started with email links because that's the easiest way for mainstream users to get started. Magic practices progressive disclosure religiously and the goal is to eventually graduate users into more sophisticated forms of login such as webauthn and mobile authenticator apps. Under the hood, Magic uses decentralized identity (DID), developers only need to deal with DID tokens (signed by user private keys) to grant user access to their backend resource server, and the front-end key management form-factor can be very flexible (magic links, mobile authenticator, webauthn etc.) without having to change the backend code! This is a bit like the Docker for auth 😆

@sunghong_sch Thanks!

@alexander_salnikov Thanks Alex!! 😄It's time we blend the worlds of Web 2.0 and Web 3.0 together! 🔥

@temirlan just checked out the site, in our case, there will be no password required to login, so one of the major use case is not quite applicable. But seem like It can also be useful for MFA and credit card payment - will def keep an eye on it!

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

@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!

@_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.

@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 :).

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

@stevealee Really appreciate these questions, it's what helps us move forward! Arthur added more to the token in localstorage question too. Regarding logging in with Yubi or our own mobile authenticator app, once that's paired with an user account, no more email link will be required, login can be achieved by tapping Yubi key or a mobile notification (similar to DUO). For users going to be using our own mobile authenticator app, there will be a special recovery process involved (inspired by crypto wallets) for users who have locked themselves out by losing their device etc.

@_seanli I guess I'm stuck when I leave my phone in the car and my partner drives off in it :) Mind you without my phone lots of pain ensues anyway.

@peteliev Thank you so much! More examples will be coming! Pricing and blockchain support. And then webauthn and mobile authenticator app support!

@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!

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

@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

@felice_feng Thanks Felice! Super excited for what's next to come and bringing decentralized finance to the mainstream 🔥🔥🔥

@felice_feng Do you have a link to TokenSets, I'm really curious to see how more people are using magic links in their sites

@vikrampatankar Sorry for not being able to include that before launch! It'll be available very soon! There will be a free tier, and we'll be carrying over the pricing from our existing key management product (fortmatic.com/pricing) and make slight adjustments. Love to hear your feedback on the price range as we are trying to make this an optimal choice for startups and growing companies too!