React User Authentication for Self-Sovereign Identity with Magic

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.

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.

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.

That was the quick start how you could use Magic and React, but how about implementing Magic in your existing React application? You can do that via npm install Magic SDK or yarn add Magic SDK.

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.

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.