In this talk, we’ll see how to build a user authentication system in react using magic, where magic provides a key-based identity solution built on top of the Decentralized Identity (DID) standard, where users’ identities are self-sovereign leveraging blockchain public-private key pairs. These key pairs are used to generate zero-knowledge proofs to authenticate users instead of having to rely on users providing passwords to Magic or any identity provider.
React User Authentication for Self-Sovereign Identity with Magic
AI Generated Video Summary
Welcome to this talk about React user authentication for self-sovereign identity with Magic Labs. Learn how the user trust model of the internet is broken and a novel solution to fix it. Understand the concept of zero-knowledge proof and the key-based model for user identity. Magic improves trust by leveraging Infrastructure-as-a-Service, secure user keys, and providing passwordless authentication. Explore decentralized identity and how it solves the authentication problem, including the use of decentralized identity tokens (DIDT) for managing permissions and authentication.
1. Introduction to React User Authentication
Welcome to this talk about React user authentication for self-sovereign identity with Magic Labs. Learn how the user trust model of the internet is broken and a novel solution to fix it. Understand the concept of zero-knowledge proof and the key-based model for user identity.
Hello, welcome to this talk, where I'm going to talk about React user authentication for self-sovereign identity with Magic Labs. I am Muhammad Shahbaz Alam, one of the developer advocates at Magic Labs, and in this talk we will learn how the user trust model of the internet is broken, a novel solution to fix it, and how to achieve self-sovereign identity in React.
We will learn what is DID, DIDT, and also how to build your own. So let's understand how the trust model of the internet is broken. Users think of passwords or secrets specific to them to verify identity and hand them off to apps owned by various companies. 59% of all users reuse their password across applications. Users trust the companies that they will store the secrets securely and responsibly, but many companies don't have proper authentication and prior knowledge of security, leading to security breaches.
Users access the company's services by showing off the secret each time they log in, and every time the secret is shown, there's a risk of exposing it to hackers. Companies might get hacked and lose users' secrets, along with their trust. 48% of customers never come back after a breach. The Equifax breach has cost them at least $4.1 billion. Hackers use stolen secrets to impersonate users to access their vital online services. This problem compounds to the point where the user's identity is no longer in their own hands but controlled by large corporations. Building your own Auth is very expensive. It requires security and infrastructure expertise. It requires security and privacy compliance. Ensure global availability at scale. Keep updated with the latest security trends. Ensure email SMS delivery. Reliability implements internationalization to enable access from a global audience. Also, defend against DDoS and spam attacks. I'm here to present a novel solution to fix all the problems.
In this part, let's understand what is zero-knowledge proof. In Zero-Knowledge Proof, a private key owner does not need to reveal their private key to prove that they own the key. What people tried before magic is a key-based model. Instead of users thinking of secrets themselves, they use blockchain-based public-private key pairs as randomly generated to access apps. It has its pros and cons. The pros where users have complete control of their identity. Companies can no longer see the user's secrets. And user uses the same secret to access apps, which is a cleaner trust model.
2. React User Authentication with Magic Labs
The cons of using keys on the internet are the risk of losing them and the unfamiliarity of the concept for mainstream users. Magic improves trust by leveraging Infrastructure-as-a-Service, secure user keys, and providing passwordless authentication. It also ensures non-custodial trust optimization through delegated key management. Magic decentralizes identity, enabling self-sovereign identity. The novel solution recap involves zero knowledge proof, delegated key management, and staying non-custodial. To implement this in a React application, use the NPX make magic scaffolding with the Hello World React template.
The cons is users are likely to lose their keys, which will log them out, as well as lose their online identity, or worse get them stolen. The concept of using a key on the internet is too unfamiliar to most mainstream users, which is mainly because of bad UX.
In zero-knowledge authentication, a user signs a piece of data using its private key and sends it to the server as proof. Server then receives the proof, runs standard stateless cryptographic recovery methods on This means that the user no longer needs to send a secret to the server in order to validate their identity, and server no longer needs to store this class of information. Better login experience.
Let's learn about how Magic improves the trust so far, using a delegated model. Magic leverages large Infrastructure-as-a-Service and secure user keys with hardware security modules, with technology that hides and protects user private key from companies and even Magic. It adds additional pros, which is Magic provides familiar passwordless Auth UX. To use this for them to retrieve their keys, it's a better UX, and users can no longer lose their keys. Magic doesn't store passwords, and can't know user keys or secrets, which enables more trust and security, and it has native support for multiple blockchains.
One con is that it relies on single infrastructure as a service. And in the novel solution series, we have to be non-custodial trust optimization. So Magic's DKM, that is the delegated key management architecture, delegates critical encryption and decryption operation to a trusted AWS KMS and AWS Cognito, completely bypassing the Magic backend. This way Magic stay non-custodial, since Magic never sees user's private keys and therefore a better security and trust with developers and end users. This enables us with self-sovereign identity.
The first obstacle to a more authentic Internet is identity. Identity has been predominantly gated by centralized identity providers. Developers are completely dependent on these providers for user access. Rolling authentication and security from scratch is extremely challenging to keep secure, scalable and reliable, which is leading to the vast amount of user data and credential breaches. Magic solves this by decentralizing identity. Instead of centralized identity provider signing auth tokens, you users are the one signing auth tokens with their, with your own private key, enabling self-sovereign identity.
So let's understand the novel solution recap, which is attaining self-sovereign identity using zero knowledge proof, delegated key management and staying non-custodial. Let's understand how we could achieve this example in React application. So this is a demo link. Anyone in the chat can see how the demo looks, what I'm going to show by visiting react-submit-magic.purrsel.app. We will start by using the NPX make magic scaffolding with a template what we have prepared for you, that is Hello World React. Run that in your terminal. You will be greeted with this. You just need to create a project name and it will ask for a magic publishable API key. You can get your own by visiting magic.link and sign up for free.
3. Using Magic and React
Visit the dashboard, create an application, and copy the test publishable key. Paste the key, choose your NPM client, and wait for your application to be ready. Enter your email ID and receive an email from Magic with your application name and a login button. Once logged in, see your user status and a logout button. The Magic CLI scaffolding provides a code structure with components like apps, callback, loading, login, profile, index, and magic.js files. Import the magic SDK, use it in the app.js file, and explore the code examples for login, callback, and profile. Implement Magic in your existing React application by installing the Magic SDK via npm or yarn.
And visit the dashboard and create an application and copy the test publishable key. Then paste that key here and choose your NPM client. Within time, your application would be ready and you will be greeted with this screen. This is what you see in the demo application which is react-summit-magic.vercel.app.
Then just enter your email ID which would enable a popup which would say that check your email, be emailed magic link to your email. And at this time, don't close this tab. You will receive an email from Magic with your application name and a button to login. And then once you are done, you will be greeted with your current user status showing your email ID and a logout button. So let me show how it looks in a react. In your terminal, you just need to run that, create an application, paste in here, choose your NPM package. And within seconds, your application is ready. Thanks for Mary-Chris for making this quick video. She's also, she's a colleague at magic labs. And then let's see what the magic CLI like the scaffolding gives us. So it gives you this particular code structure which has components like apps, callback, loading, login profile, and an index file and a magic.js file. Also there's a .env file.
So everything happens here. You can create like this or you can have different approach which I will show later on. Just import the magic SDK and pass on the publishable magic key. And then use in the app.js file. This is how we use it. Example using login, callback and profile. You can have a better understanding of the code by visiting this link. The callback js months and this is where we try to login with magic credential in the URL query. And this is simply a loading status when we wait for that, when we wait for the login to happen. And this is where everything happens, the login.js which performs login actions via magic's passwordless flow. Upon successful completion of login flow, a user is redirected to the homepage by history.push. And then there's a profile page which displays user's metadata. You can have a better understanding of the code by visiting this link on GitHub.
4. Handling User Authentication with Magic
Learn how to use environment keys in .env file or the Magic.js file to handle user authentication. Pass the publishable key and use Magic.auth.login to log in with a Magic link. The email received after clicking the button will log you in.
You either, it's always recommended to use your environment keys in .env file, but it's up to you how you are going to use it. One way is to use Magic.js file and have everything there. The other way is that having everything in single file, something like this, which imports the Magic SDK, pass on the publishable key, and then call Magic.auth.login with Magic link and pass on the email ID. Email that log in with magic link has various parameters, for example, email, show UI, or redirect UI. So it's up to you how you're going to use that, but the demo has redirect URI. So once you click the button, what you receive on your email, you will be logged in from there itself.
5. Decentralized Identity and DID Tokens
Learn about decentralized identity and how it solves the authentication problem. Understand the DID format, including the scheme, method, and unique ID. Explore decentralized identity tokens (DIDT) and their use in managing permissions and authentication. Discover the structure of a typical DID code, including proof and claim. Generate a DID token using pseudocode and learn about its keys and encoding. Magic handles key management and offers resources to learn more. Connect with me for any questions and explore the decentralized identity space.
So how you could use DID and solve Auth problem without using the Magic SDK. So let's understand what is decentralized identity. A decentralized identity is a new type of identifier that is globally unique, resolvable, and has availability, and cryptographically verifiable. DID tokens are used as cryptographically generated proofs that are used to manage user access to your applications resource server.
For self-sovereign identity, which can be defined as a lifetime portable digital identity that does not depend on any centralized authority. So this is how the DID format looks, which has a scheme. It includes DID, also has a DID method, which depends on read, write, update, and delete based on what you want to perform. As well as includes, for example, UUID, that is the unique ID. And at last, it has a DID method specific string. It depends on the DID methods you use. Visit this link to understand more about the DID format.
Let's understand about DIDT, that is de-centralized identity tokens. By adapting W3C's DID protocol, the DID token created by magic client SDK leverages the Ethereum blockchain and elliptic cryptography to generate verifiable proof of identity and authorization. The proofs are encoded in lightweight digital signature. The lightweight digital signature that can be shared between client and server to manage permissions, protected routes, and resources or authenticate users.
This is how a typical DID code structure would look, which consists of proof and claim. Proof is a digital signature that proves the validity of a given claim. And claim is nothing but a data representing the user's access. And proof is signed data with Ethereum's personal sign method. Visit this link to understand how the personal sign Ethereum link, personal sign method on Ethereum works. And then there is binary to ASCII conversion encoding from proof and claim. DID token specification has its keys, for example, issue date, expiration timestamp, not valid before timestamp, issuer, subject, audience and it adds an encrypted signature of arbitrary serialized data and then a unique token identifier, which is something like this. This is how you generate a DID token, which is a pseudocode, which has IAT in this format, expiration time with the lifespan, issuer, who is your issuer, which uses the DID format, which uses the DID and the DID method and the specified string, then the subject would be, what would be the subject and then the audience and NF, NBF, which uses this format and then a token identifier. This signs the claim with the user's private key, this way the claim is verifiable and impossible to forge. And everything is encoded using binary to ASCII.
So this is how you generate a DID token. I hope you would have, you learned a lot about how to manage decentralized identity. So it's not about building your DID and how you build it. So Magic does a lot of things under the hood. It manages the key in very unique way. Everyone can generate a DID token, but it depends on how you're going to manage that. To learn more about how Magic handles its delegated key management, visit these links, as well as learn about Magic from Magic Docs and Magic Guides. These are the ways you can connect with me. Feel free to reach out if you have any questions around any topic, and I'll be sharing the slides link after this talk. I hope you had a wonderful day, and this talk has given you a vision to think about a decentralized identity space. So, bye, have a good day.