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.
@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
@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
@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
Password-only security is obsolete and dangerously insecure. I've been hoping for a solution like this for more than a decade. The danger and the stakes for user authentication security are growing exponentially by the day. As we add more valuable asset transactions to our applications, the need for non-custodial solutions with minimal vendor lock-in grows as well.
Magic was easy to learn and easy to integrate with EricElliottJS.com, and we intend to use it as our exclusive auth solution for all of our new applications. The Magic team has created an elegant solution to a very challenging problem that every application team needs solved, but almost none should try to solve alone.
Magic is a non-custodial key management solution that stores user keys in cloud-based Hardware Security Modules (HSMs). Private keys are never exposed to the internet, and your users don't even need to know they exist. All users need is access to an email address and the ability to click a button. It's the most user-friendly, secure authentication solution I have ever seen.
Report
Your "Security" section is a great read in and of itself. Thanks for this product. How common is the "passwordless" approach at the moment?
@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!
@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
Indeed, passwordless login is pretty magical. Great job!
I'm really impressed by this.
Let me start from the landing page - immediately gives you all the information you want : what is this, why would you need it, what are the benefits and how to use it - without cluttering and while looking pretty good (not a fan of the mint, even tho its associated with security).
The SDK is simple and readable, the documentation is nice and readable - and answers all of the questions I might have regarding present and the future of using Magic.
And the product is awesome! First time I saw a magic link like that I was wondering why more services don't use it, and this makes it super easy to implement. And I love that the blockchain side is hidden from the user but still accessible - as it should be!
Mad props! 🌊
@ianissoawesome Thank you so much for the kind words and great feedback Ian!! 💜
Report
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
> 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!
Report
@_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 :).
Report
@arthur_jen ooh so no refresh tokens with Magic!? \0/ \0/
Report
Wow this is so exciting! I hope this starts a new industry standard in the near-future.
@louis_xu Thanks Louis! We aim to really push the envelope forward for the identity space. Which is why we adopted some future-proof standards like W3C's Decentralized ID (DID), as well as using blockchain keypairs to enable sovereign identity (user owns their identity and can move them to different applications anytime) - all without a centralized identity provider. Magic in this case is a key management service that helps generate these DID tokens which is an open standard for any application to do auth with regardless of how the keys are managed!
Zelos
Magic
Magic
Memo
Magic
Superwall
Magic
Magic
Magic
Magic