Authentication Beyond Passwords

So, hey, my name is Juan. I'm a developer advocate at Okta. I have been a software engineer for over 20 years now, working in all kinds of different projects. I work mostly for big corporations like Siemens and Cal Size. And now I'm working at Okta, which is a completely different type of organization. And the main reason why I do software engineering is because I love to build stuff, but just software stuff. Don't ever ask me to build an IKEA furniture because I'm terrible at it. But as long as it comes to software, I always find my way around that. You can find me online in most social media platforms at BA JC Martinez. So, yeah, you can follow me there if you like to connect and have further discussions about the workshop or just software engineering topics in general, I'm always posting stuff.

So the workshop. So today's workshop is going to be about the future of authentication and how the future of authentication is passwordless. At the beginning, we're going to have a short presentation on introducing the topic, but then we're going to get all hands into code and implementing a Next.js application that is going to allow users to sign up and log in using passwordless authentication flows. We're going to discuss that into a lot of detail today.

Also, this is going to be an interactive session. So if you have any questions, if you have any comments or anything you would like to talk about, please feel free to use the chat. I would love to do this as interactive as possible as you follow me along creating the application and working on the code. So it doesn't feel just me doing a presentation of everything, but it's actually all of us building in public in a way.

So let's get started a little bit with our presentation. That was enough a little bit about myself. And oh, look at that. I just got a notification here on my phone that says that my train to Berlin is here. So that means that I get to jump on the Deutsche Bahn train and enjoy my four hour ride to Berlin. Now, while I'm on the train, I see the person that is responsible for checking on the tickets. So I take up my phone, and I open the Deutsche Bahn app. Just to find out that I'm not logged in, right? And as the guy is getting closer, I need to enter my username or my email and password in order to access my ticket. So I can present it to him. But I kind of like forgot what my password is. And now this is a total nightmare scenario because he's approaching I don't know what my email that I used to sign up wasn't like my regular email was like my company email. What was the password that I use? Like, I'm terrible at this. And I'm not the only one because passwords are easy to forget. Right?

I receive an email. I reset my password. The guy is already standing next to me, speaking to me asking me for my password. I try my best German to tell him that he needs to wait because I'm not logged in. And everybody's kind of like looking at me. And yeah, this whole situation is so frustrating.

A process that should be as easy as using my phone, the phone knows who I am. The phone knows my face or my or my or my deed or my thumbnail prints on my fingerprints, right? So the phone knows who I am, the phones know that it's me. And yet when I open an application, I need to go always through this complicated process of signing up, user emails, passwords that I will forget, using password managers and the thing gets always very complicated.

And so passwords are not only difficult, they're always they're also easy to guess or crack like in most services. And I'm I'm a tech savvy person. So I won't do this. But I've seen this firsthand, for example, with my wife and with my kids, where they put passwords that are just simply too easy. 123456 is to be my kids favorite password. And then I got us a family plan for one password. So everybody knows the passwords around right. And I introduced my wife to the password managers wall and all of the staff. And then all the sudden, I'm on WhatsApp and I get these very cryptic messages from my wife, just a bunch of characters and numbers and stuff. And I'm like, like, what is happening? What? Why are you sending me these weird stuff? Or is what's up broken? And she does not know. I mean, I have the one password app on my phone, but I don't know how to use it on the computer. So I just copy and paste the passwords on WhatsApp send them to you. So it's safe. And then use WhatsApp on my computer to copy them into my browser. And I'm like, oh, God, please don't. Please tell me that I had that wrong. But no, that's, that's actually what happened. And it happens quite frequently, no matter how many times I said that, it is still happens. And if not, she's reusing passwords, right. And this is a very common scenario where we like one password, we think it's safe. And then we use it throughout multiple services. But as passwords can be stolen or compromised. We all know on the web, we get the news from time to time that passwords get leaked in the web. And then we end up in the bad situation with actors getting the password from one service can access and all the services that we use, which is pretty bad news for us, right now that we depend on digital services so much.

And then we end up in the bad situation with actors getting the password from one service can access and all the services that we use, which is pretty bad news for us, right now that we depend on digital services so much. So, so over the years, engineers have been thinking hard, and they were thinking, okay, so passwords are bad, how we can make them safe? Well, we can add multifactor authentication, we can add one time passwords, we can add biometrics, or hardware keys, everything on top of passwords. So now, not only I need to have, not only I need to know my passwords, but now I also need to have my phone to receive an SMS to be available or to check my one time passwords, for example, in a Google authenticator app, or I need to, on top of my passwords, provide my biometrics. And things get skipping, getting more complicated. And the more complicated things are, the most likely users are going to take shortcuts. So every time a service asked us to set up multifactor authentication, most of the time people will hit the remind me later button, or they don't ask me again, but only a few people will actually go through the process of setting up multifactor authentication. And in the case they do that, most people will opt to use SMS because it's the most convenient, though is the less secure option. So clearly, what we are doing is really not working. And we need a new solution. So what is the solution for the future and that identity engineers are talking all about? And it's passwordless, right? So it is time to get rid of passwords, and we need a better solution, we need something completely different. This is the only way we are going to move forward. But what is passwordless, right? Because it's just like a password word. So passwordless is authentication is the process of verifying a software's user's identity with with something other than a password. I mean, yes, passwordless means there's no password, right? I think that's the easy definition. And why do we love passwordless? Because it's more user friendly, right? All these things that I told about passwords have been a headache, and it's also safe. It is safer than passwords. So we should do passwordless whenever we can. But there are multiple ways to do passwordless. There's magic links, that's probably the less secure option. This is when on a service, for example, Slack, you put your email address, and then you receive a link in your email and click it as a link, you're automatically logged in into that service. That's pretty good, as long as your email account is not compromised. And yeah, so it's not the safest options. Then we have social logins, which are great for security. I love social logins, and I try to use them whenever I can or I used to do that. And we get to that in a minute. But social logins allow us to log in with our Google account, with our Apple account, with our Facebook account, and all of these social providers into different services. So they're great, because they are super easy. You're normally already logged in, in one of these accounts on your browser. So whenever you want to access a new service, you just click login with Google, and then you are automatically logged in. So it is great, it is safe. But from a privacy perspective, it's not ideal, because every time you register to one of these services, or every time we log into one of these services, you are giving that information to Google, you're giving that information to Facebook, you're giving that information to whomever your social provider is, and then they are going to use that information to provide you advertisements and who knows what else, right? So as the world is moving into a more privacy focused world, and we are more concerned about our privacy, we are trying to move away from this social login, which has become quite popular in the past few years. Yeah, exactly. Like we have here in the comments, social login, your data is shared, right? And you don't really, once you share your data, you don't really know where it's going to end up. So even though great, and much safer than MagicLink and Passwords, you're compromising your own data to these companies that you have to trust. So what other options do we have? Well, the other option is WebOfN. And WebOfN is a W3C recommendation for defining an API that lives in browsers for the creation of strong, attested, scoped, public key base credentials. So it's basically a way of using the hardware that you have on your laptops, and private public key cryptography to provide a strong method of authentication. There is a QR code on the screen that points to the WebOfN.me website. If you follow that website, if you scan the QR code, you'll find that there's a lot of information about what WebOfN is, how it works, how it's implemented in the in the browser. And what I love about that website is there's a flow where you can trigger the workflow. And you can see how the process from when it starts until the end is reflected between the client and the server, and how all the information is being shared. So it's a fantastic resource, WebOfN.me. I recommend that you check that out. I'm going to also post it here on the chat, if I can. So, WebOfN.me. There we go. So, okay, so to summarize, so WebOfN is basically two things happening in two different places. So you have a process to register a new user, and you have a process to authenticate a new user. And the process will happen in both the client side and the server side. And now we're going to see the flows of these two happening. So on the user side, we have the chart here that reflects the user registration. So we have this complicated API that I copy and pasted here for the reference. And then on the right side, we have the flow, the authorization flow. So it is quite complicated. It involves having a user, a user agent, which is normally a browser or web applications, and relying party. A reliant party is normally a server. It could be one of the social providers like Google, Facebook, Apple, etc. Well, not Facebook. They don't support this, but Google, Apple. But it can be a reliant party, which is a service like Auth0, that provides authentications for building third party applications. And it also requires an authenticator. An authenticator is normally a hardware device. It could be your modern laptop. It could be your phone using Face ID or Touch ID, or the equivalent on Android for the fingerprint scan, or it can be a YubiKey. And I have a YubiKey here just to show you what that looks like. But yeah, so this is a YubiKey, it's a USB-C key that you can connect to your laptop. And this key internally has a private key generator. And every time we push the button there on the registration flow, it will generate a new private, public key. And then we are going to use that to log into websites. So this is the best way to secure your accounts, because it requires you to have physical access to the key.

If you don't have the physical access to the key, then you cannot register or log in into any of the services. So let me connect that back because we're going to need that later. But the process for registration goes more or less like this. So you start with a user asking for a registration attempt, that basically means using the register button that goes to the authorization server, the reliant party saying, give me a challenge. The reliant party generates an encrypted message, which is what we call the challenge and it gets sent back to the browser. And then the browser uses that challenge and sends the challenge plus the authorization request to the device. And the device generates, based on that information, a private key and a public key that relate together. The private key gets saved in the device while the public key gets sent back to the browser. And the browser sends that public key plus the challenge back to the reliant party. And this is very important because the private key never leaves your device. That means that your password, the private key is going to be your password in this scenario, never, ever leaves your device. You only work with the public key. And it's perfectly fine to share your public key, because the public key doesn't allow you to log in. It is only the private key which allows you to log in. And because it never leaves the device, we said that this is phishing resistant. No matter how hard an actor wants to get access to your system, or wants to grab your password, or wants to do a man in the middle attack, where they basically intercept your network traffic, they will not get any information that is critical for them to gain access to your accounts. So it is the safest of the options. But similar to the registration process, we have the authentication, which again is very similar. It starts in the user, clicking the login button, going to the reliant party asking for a challenge. In this case, the challenge gets back and we sign. So now in this time, we sign the challenge with the private key. And then we send that signature back to the reliant party. And the reliant party will compare that signature with a public key we previously registered. And it will tell us if you have access or not. And this is the part where that is great, right. So even when we are authenticated, the only thing we send is a signed challenge that is only valid for a short period of time. And then the validation is only done after a public public key. So no, there are no compromises during the registration process. And there are no compromises during the authentication process in which we will expose our private key, our password, in this case, it always lives in the device. And this is why it's super important not to ever lose that device. So normally when we work with hardware keys like the Yubico that I just showed, you will normally have two of those. So I have one with me that is always with me in my keychain. And I also keep one always on my computer or always at home. That way, if I lose the one that I always have on the go, I always have a backup. So on every service that allows me to use this kind of registration authentication methods, I always register the two keys. Otherwise, I'm at the risk of losing it and losing access to my account. There are other ways we are going to see later where you can use, for example, your, your computer and your Chrome browser to share those private keys safely. Or for example, if you're using Apple devices, you can share those private keys using iCloud Chain. That way, all your Apple devices will have access to that private key. So that's a way of solving the problem of having always needing to have the hardware key. So there are ways you can share your key across multiple devices in a safe environment, either using Apple, Apple keychain, or using the equivalent on Google Chrome. Yeah, so password managers like BitWater and OnePassword allow you also to do that. Some of them are still like in beta. So I don't recommend like you start maybe using them right now, but they are getting better. And so how do you implement this? So we're going to see two ways. One of them are going to glance very quickly. And then we're going to cover the better option in depth. So the first one is you can go ahead and build this on your own, which is something I don't personally recommend. Because then you have to build the typical username password authentication flow, you have to build a multi factor authentication, and now you need to build also passwordless logins, right. So there are API NPM modules you can use like SimpleWebOutN. I have the QR code here to that project, it is an open source project. And in that project, you will have to provide four different APIs, the registration is start, which generates a challenge for registration, and the registration verify, which verifies that that challenge got properly signed. And then same for the login, the start, generate the challenge and verify to validate that challenge against the public key that you start. Now, SimpleWebOutN will give you the basic methods on how to verify on how to start, but it will not give you any recommendation on how you generate that challenge, it will not give you any recommendation on how you store the public keys. So it's, it's going to give you like the bare basics to get it working. But then it's up to you to implement these using the best practices. And this is why kind of like I don't recommend this. If you go this path, and you're not really an expert on this, it's going to be very hard to maintain the safe. And then you don't introduce bugs later on, that is going to imply that you're going to expose your user information, right? That's something no one wants to take the risk on. But it's good to know that we have open source projects that are embracing the future of passwordless, and they are already available, so you can check them out.

Okay, so we talked about a little bit powerless, but how does it how does it really look? I'm going to share like a small video. Hopefully, you can see that over Zoom. But this is on my mobile phone. I have an application that I created, and I click Continue with a passkey. It is my case, I'm using one password, and I click on Continue, it prompts me to use my face to log in. And once I put my face boom, I'm automatically logged in. I don't have to enter any passwords, I don't have to enter my email, or anything like that, because I was already registered. And my public key was already registered with the service. So it is super easy to log in, it happens automatically. The only thing you need to provide in this case, because of my password manager, it asked me to log in with either with my face ID or with my touch ID. So super easy to log in and no more problems with the Deutsche Bank. Hopefully. Yeah, so, so we know now where we are then. So this new W3C recommendation is better than passwords, because it is based on private public key authentication. It is phishing resistant, because the private key never leaves your device. Not at least in the sense that is shared with the third parties, services that you're using to log in or authenticate to. And you only store public data on your database. So even in the unlikely scenario, where you implement something and your database gets leaked, and bad actors get access to your public keys, that's fine. That's fine. They cannot really do anything with that. If you don't have the public the private key, then you cannot sign the messages and you will not be able to log in. So even in that unlikely and bad scenario, you are still safe. And all of that while providing a better user experience, which is fantastic, right? Because we get all the plus and a little bit of the minus right? There's, there's this thing where we still need to educate people to learn about this. Like, if people start seeing these kind of like flows, they will still not know how to react to it, because everybody's so used to username and passwords. When I see over the next few years as Google and Apple and all these giants keep on pushing on web auth n, it's gonna get better and people is gonna get more used to it. And this is gonna be the future just in a few years. So I'm pretty excited about the future of passwordless.

So so far everything we talked about is web auth n. And when you take into account web auth n, plus biometrics, and a specific protocol for sending and receiving the challenges, then you're talking about PaaS keys, which is pretty much what we have been talking about, right.

The major difference between PaaS keys and web auth n is that PaaS keys are automatically unique for service. So you even though you can have a private key and a public key per service, web auth n doesn't enforce that. You can have the case where you use always the same private key and public key to log in into all your services. And that will be a bad idea. PaaS keys automatically take care of that. So they are also bridge resistant, and phishing resistant. Pretty much the same benefits that we had with web auth n. And in fact, PaaS keys are an implementation of web auth n.

So yeah, so where can you use PaaS keys today? Well, you can use PaaS keys on any application that is built with Auth0 by Octa. And we will get into how you can do that. They're going to build an application using Auth0. And you can do all of this for free. So there's zero free cost with Auth0 up to 7,000 monthly active users. That's plenty enough for us to test and to even go production if we would like to. Google also supports PaaS keys and Apple, of course and GitHub and many more. Our services are now supporting PaaS keys. If you want to check out which services do you use PaaS keys, you can visit the website paaS keys.directory. That's a website created by our friends at 1password and PaaS keys.directory, you put the name of your service there and it will tell you if it supports PaaS keys or not. So the list is continuously growing. And we are pretty excited about that happening.

So yeah, how do you feel so far? Do you have any questions? Have you used PaaS keys before? Do you hear about it? Is it like something totally new to you? Are you even excited about the future with PaaS keys? Or you're like, man, I'm fine with my passwords? Like everything is valid, right? So please share in the chat what your thoughts are. And you're going to get started building something right. So again, if you want to connect with me, I'm going to leave that on the screen. For a few minutes, you can scan this QR code at VHACMartinez on social media. I'm going to be sharing the slides and everything related to this workshop later also on Twitter, LinkedIn, Instagram, that kind of stuff. I'm not on TikTok. But if everybody asks for maybe I can create an account. But yeah, share, share me your thoughts. Share me your ideas, what you think about passwords, and let's start working on it. Finance is using PaaS keys. Oh, that's interesting. I didn't know about that. It's good to see. It's good to see them implemented. I'm going to share on the chat a link and a password. This is going to be what we're going to be following on the workshop. So the URL is developer.auth0.com slash resources, blah, blah, blah, blah. You can click on that link and use the password, react-based. That will give you access to this website. And we're going to be following this workshop together. The workshop will give you all the instructions that you need to build an application using Next.js and using Auth0 to support both social logins and also PaaS keys. So we are going to go through all that process together. It's going to be fun. It's going to be simple. I think we are going to finish ahead of time because it is quite easy to do. So if we have some time at the end, we can also have some rounds of questions. And of course, we are also going to explore a little bit more of the features that come out of the box with Auth0. Now, I haven't worked with temporary logins. So I have worked with magic links, which is similar to what you just mentioned. Normally they last for a few days. I used Auth0 to do that in the past. And I also have like my own implementation, which I don't recommend anyone follow. But yeah, yeah. So yeah, I did that in the past. I don't do that anymore because I don't really, when I try to log in now on Slack, and it asks me to do that, it is quite annoying, especially when I try to use my phone, because then I need to like completely stop my flow, go to my email application, clicking on that link, which opens my browser, which then opens Slack. So it is quite like, it's quite annoying from the user experience. So I have left that behind. And I'm normally now using social providers, username and password for my applications. And just in some applications, that I'm building, I enable Fastkeys to see how users kind of like react to it. But it is on an experimental side on my side, because users are still not very used to it. So when they see it for the first time, they are a little bit confused. But it is getting better, it is getting better, like especially around the technical community, people is becoming much more aware of this new technology. So I think we'll see a lot more happening. So yeah, so hopefully everybody got time to click on the URL that I shared with the password react days. And if everybody is there. Yeah, so the first, the first page is just an introduction to the workshop. It has some information about me and how you can connect with me on Twitter, or Github. I'm also on LinkedIn.

You can find me with the same at vahcmartinez. And yeah, so we can, we can go ahead and start by clicking the next button here, or finish button, I think sometimes says, and move on to next JS Fastkeys authentication.

And the first thing we are going to need is we're going to need NodeJS, we need to run a React application or a NodeJS application. And you're going to need to create a new account in Auth0. And when you do that, it's going to ask you to create a new tenant. The new tenant screen looks something like this. I'm going to do that here together with all of you. So it's super easy. I already have an Auth0 account. So I'm just going to log in. And I'm going to continue with my Google account. See, I don't use passwords. In this case, I trust Auth0. So I'm going to use my Google account to log in that. And what I'm going to do, which is the same process that is going to guide you through when you try to create an account, it's going to ask you to create a new tenant. passwords needs to be supported by browsers. Yes, that's correct. WebAuthn, you can look for WebAuthn. And I can use I think it's a service. And it will tell you what are the browsers that support it. And all the major browsers support that now. So Firefox, Chrome, Safari and this is also, yeah, also mobile, Chrome, Safari. So all the major browsers do. And on the case of Edge here, it works with the new Microsoft Edge. I think it's called. Yeah. Okay. So yeah, I see it. Also, one more night. So if you're on the latest versions of your browsers, it is likely to work. I haven't tried MetaQuest. You need a form of biometrics normally when it comes to the browser. So will be interesting to see how will you apply biometrics. In that scenario, but it will be an interesting thing to try. I don't know. Maybe I should get one and try maybe. Maybe that's the excuse that I need to get one of those. Alright, so when you're on, when you are getting a new tenant, so you normally will get like a screen like this, where it's going to ask you to enter your tenant name, your tenant name is basically your account name. Usually you create one tenant per application, you can have even two tenants per application, you can have one for your development environment and one for your production environment. Yeah, I'm gonna, I'm going to create one, I'm going to use my personal account. I have a have a corporate account, but I'm going to use my personal free account, because we don't really need to pay for up zero in order to use all these features. And then when it comes to the region, I recommend that you take the EU if that's where you live. Because that way is going to be the fastest compared to like the other region. And also the EU is always following the latest updates. Fast keys is roll out to all the regions. But sometimes we have features that are rolled out in the region independently. But for now, yeah, I'm going to stick to the EU. And I'm going to create these with react. They JC, just in case someone took my name, which needs to be unique for region. And on the environment, I'm going to select development, though nothing. It's nothing wrong to select production here. When we go to create an application for production, you can do that completely for free with a free, or zero account up to 7,000 monthly active users. So it's plenty, plenty enough. But for now, I'm going to go development, just something that I want to show you. Hopefully, everybody can see well my screen here, maybe I'll get the browser a little bit bigger and increase the font. So when you create your tenant, you will arrive to the first screen, which is kind of like this tutorial that will ask you if you use Obsero before, or if you are a new Obsero user. And yeah, so hopefully everybody is in here now. So let me see, we have some people. Just got a notification. Some people are waiting to join. So I'm going to go now back to our workshop.

And okay, so we already did the step of creating a new account on a new tenant. I'm going to click on Next to go to Social Connections 101. And social connections is this we have been discussing that you can log in using like your Google account, your Facebook account, etc. And of course here in the workshop, we also explain some of the benefits and drawbacks that we already covered during the presentation. So we're going to go ahead and get started with social connections. And this is super easy. So once you register to Obsero, Obsero has a protocol, the universal login. And this is this login screen characteristic of Obsero. And this is what your applications are going to use to authenticate your users.

And then Obsero is going to send the information back of that session back to your application. And that will happen automatically with our SDKs. We'll see that in great detail. But to get a feeling of the Obsero universal login screen, you can go ahead and click here, the Getting Started link on the top left of your Obsero dashboard. And that will get you to the Get Started screen. And if you scroll down, there's a box here that says try your login box. Now you can click on Try it out. And when you do that, you will automatically see your screen, your universal login screen that we said welcome. It will show the name of your application, in this case, the name of your tenant. So that's the only thing we've set up so far. And it's gonna use the typical email address and password workflows to sign up or to login. Right now I don't have any users, so I cannot really login, but I could sign up. And it also has the option to continue with Google. This comes already by default with your Obsero installation, you can change that and you can customize this. And if we take a look to the up, to the upper right corner, we see that there is an exclamation mark here that is in red and kind of like highlighting, if you click on that, it's telling us that we are using developer keys. And this is related to the Continue with Google button. Whenever you want to use the Continue with Google button, you need to register your application with Google, and you need to create what is called the OAuth consent screen. We haven't done that because we just created our Obsero account, so Obsero is not aware of that. And thus, it offers by default an Obsero application. That works, if I decided to, I could click on Continue with Google, and it will take me to Google to authorize with my account. So that will work for developer environments or for dev environments, but it will not work in your production environment. So you need to be aware of that. If you want to use the Continue with Google button on your production environment, you need to fix that. And how do you fix that? Well, on Obsero, you can fix that by going to the left side menu here in authentication. And then you can click on social. When we click on social, we see a list of all the social connections that we currently have. And in the case of Google, which is the one that is currently enabled, we see that we have this warning sign with a triangle and exclamation mark that says active with Obsero dev keys. So to fix that, you can click here on the social connection, Google OAuth 2. And when that happens, make this a little bit bigger because it doesn't fit on the screen. So when that happens, it opens this form, where you need to provide a client ID, a client secret, and the allowed mobile client IDs, which is information that comes from Google. So this, you will have to have an account at Google Cloud. And it is not something that costs, it's something that it's a service that is free, and it allows you to log in with Google. If you have any questions on how to do this with your social provider, there's always a setup guide here on the top right corner. And if you click on that, it opens this popup that explains a little bit what the Google Gmail social connection is. And then if you click on the right arrow here, you can go step by step, it tells you to sign up for a Google developer account, to create a Google project. And step by step, it will guide you on how you need to set up your OAuth consent screen, in order to get it working with your Auth0 account. And at the end of it, you'll have all the information that you need. And then you can try your connection again. And when you do that, yeah, it's going to go into the sign in with Google account, and then you will be able to continue like you will normally do. And yeah, in this case, it works right and it gives me some information about my Google account. What is my ID? This is an ID generated by Auth0. But the rest of the information is coming from Google, like where's my given name, my family name, my nickname, name, etc. There's also the email that is coming from Google, but we are not showing that here for privacy reasons. There's also a photo that Google selected for myself, which is this one I need to update. But that's another story. But yeah, Auth0 will automatically import all the information from the social provider and keep that information for the next time you log in. So that's how you set up your Google connection. But as easy as it is to set up your Google connection, you can add additional connections by using this Create Connection button. And when you do that, it's gonna go into the Auth0 marketplace, which is a place where Auth0 and other third party providers can add their own authentications. Like for example, we have all the common ones. So you have your Facebook, your Apple, Microsoft, LinkedIn, GitHub, like there's over 70 different connections that are already pre-established and work automatically with Auth0. And you can have them in your free plan. You can go to Auth0.com slash pricing. And on the free plan here, if you click here, Compare Plans, you can have up to two different social connections for free. And up to 7,000 monthly active users. So you can have your Google and your GitHub, for example, or your Google and your Facebook, or whichever two connections you would like to have. And again, no matter which social provider you choose, like for example, I could click here on Facebook, it's going to automatically send me to the guide and allows me to continue always with information on what do I need to do in that platform in order to get it working with Auth0, which normally involves, again, like the same amount of steps, like having an app ID and a secret at minimum. And in the case, for example, of Facebook, you can even tell Facebook, what kind of information would you like to have from Facebook? So you can even retrieve through Auth0, what are the likes of the user, the gender, the location, so all that kind of information, which is going to show up on the Facebook dialogue as part of the requests that we do. That typical pop up asking if Facebook will give access to the application. So, yeah, so you have over 70 different providers here. Normally all your well-known social providers are in here. But if you happen to work with another provider that is not here because it's new or because like for whatever reason we don't have it, in here you can create a custom social provider. And as long as the social provider follows the OAuth 2 protocol, which is very common for this kind of scenarios, you will be able to configure in here by passing all the information manually like your authorization URL, your token URL, scope, etc. So, yeah, you can always connect Auth0 to any OAuth 2 provider of your choice. It's quite easy to do. All right. Any questions so far? All right. So we have seen Auth0. We have seen the login box. We have seen social providers, how do they work.

And now we are going to continue with the next step in the workshop. So within the free plan, you can visit Auth0.com. You get two social connections on the free account. Look, now it's 7,500 monthly active users. That means if a user doesn't log in in a given period, it doesn't count towards your quota. So if they don't log in in that month, they don't count towards that quota. So inactive users don't count, which isn't enough. I have a link in the chat. What happens at the end of the quota? We will not shut down your service. So what's going to happen if you reach the limit and you don't log in? Well, it's going to be a free plan. So you will not get any more free plan. So what's going to happen if you reach the limit and you don't log in? And yeah, the free plan has been more than enough. What happens at the end of the quota? We will not shut down your service. So what's going to happen if you reach the limit and in a given month or in two months, someone from sales will contact you. And then it will walk you through the options. Yeah, but there is no hard limit. It's not like you're going to be like rich. Actually, a funny story is the JetGTP. There's some controversy around that now, but JetGTP is a customer of Auth0. And the day they went live, they exceeded their plan, like immediately. And they were able to scale regardless to, I don't know, how was it like millions of users in a day or something like that. And Auth0 scaled with them with no problem. And they started on the free plan. No one expected them growing so fast, not even themselves. So, yeah, so you won't be like cut off. Someone will reach out to you and will walk you through the options. If you want to know a little bit more about like the different use cases and all that. Like there's this in the pricing page, you have this. It's like that where you can say how many users you have and how much you will pay in the different plans. We split the plans between B2B, B2C. And then you can compare all the different options in here, in this table. And there's really a lot of things. We're going to walk through at the end if you have some time to see some of the other of the free features. So one of the paid features that a lot of people jump for is custom domains. Natively, we provide something like your app at Auth0.com. That's the domain they are going to use to log in. If you want to have the other way around, like off at your domain.com, that will be a paid feature. But there are plenty of use cases where they still use the auth0 given domain, which is your company or your product.auth0.com. Yeah. Okay. Yeah. So continuing with the workshop. So we work a little with social connections. We learn how to configure your Google or your Facebook. So we cover a little bit on that. And next, we're going to learn how to use PassKeys because Auth0 now supports PassKeys. So PassKeys are not enabled by default because they are a new technology and they are only in early access. But if you just sign up for an account, you will have PassKeys options enabled. And there are instructions here on how to activate it. So we are going to go again into the Auth0 dashboard. And we are going to go to authentication and database. So database are all the places where Auth0 is going to store your user information. So one thing you need to know about Auth0 is that by default, Auth0 will store the user information into the Auth0 database. That means that it's going to be hosted in our cloud. And yeah, and you can create multiple database connections and add them to your account. Though, you can have one active database per application at a given time. So either you use one or the other. So by default, Auth0 will create this username and password authentication. And if you click on that one, you will be able to set different configurations for it. Like do you require a username or you just want to use the email? Do you want to have. Do you want to import users into Auth0? You want to disable signups? Perhaps you just want to send invites to people and not allow like general signups. And there's also this tab, authentication methods. If you have this tab, then you have FastKeys enabled for your account. So by default, you'll have passwords, something we always have in support. But additionally, you can enable FastKeys. And by simply clicking here, I will trigger or I will tell the Auth0 that I want to use FastKeys for my account. And when I click on that, it tells me that it performs a check on my account to make sure that everything that I'm doing is correct and that I have all the required configurations for FastKeys. And it tells me that for the most part, I'm okay, except for this identifier first login flow, which must be enabled. So what does this mean? Well, I can click here in identifier first login to find out. So that takes me to the authentication profile page and this gives me a nice graphic here on the right side hand which shows me.

What my current flow looks like. So we have the typical user email and password screen where you enter all the information and then there's the buttons and then multi-factor and then you're logged in. Or you can change and say I want identifier first. And if I click that, first the user provides an email address. And after that, they provide the password or they continue with the other options. And this is required to have this set up in identifier first for FastKeys. So we will have to enable that. And to do that, we just click on it and we click on save. And then if we want to see, we can click on try. And now when I see the universal login screen, it only asked me for my email address. And after I enter my email address, it will ask me to prompt my password. This is very similar to what Google has today in other services where they split the screen in two. This is particularly important when working with FastKeys or when having other enterprise connections. But you need to know the email address to know which methods of authentication the user has. Yes, sorry about that. But let me try that again. I'm going to click again on try. So yeah, hopefully now you can read better. So now the flow we set up, it first it asks us to provide the username or the email address. And once we provide the email address, it prompts us to enter the email. This flow is particularly important, for example, when you have FastKeys or when you have enterprise authentication methods. Where you need to know who the user is before you offer them the options to login. Like for example, you can say users from my domain should only register with a social provider, for example. With a Google workspace. And external users can register with username and password. So in order to do that kind of configuration, you need to have this identifier flow. Because you need to know who the user is first, and this is a requirement for FastKeys as well. So now that we changed that. And we are here in the authentication profile. And we save that. We can go back to our database. And we can click on username, password authentication. And we can go back to authentication methods. And we can click here on FastKeys, and now we can click on to activate. And as easy as that, we are now supporting FastKeys. There are some advance configurations that we can do, but they are not required. We can directly go ahead and hit try connection. Again, now when we do that, like the form looks pretty much the same thing. But now I have this continue with FastKey button. I'm not yet registered. So instead of continuing with the FastKey, I'm going to sign up. And I'm going to use a new email address to sign up. And I should remember this one. Test two, test two. And I'm going to click continue. And now when I continue, instead of asking me to enter a password, it's telling me that this application supports FastKey. And it's asking me, do you want to use FastKeys? Or do you want to continue without FastKeys? If I click on continue without FastKeys, I will see again. Yeah, thanks. I always do that. Like if you have a Gmail account, I think all email providers provide that, the plus. Every time I register in a service, I do plus on the name of the service. Because then if I start receiving spam, I can know who sold my data. Very important. But also for testing purposes, it's excellent. So yeah, users will typically see the screen where they say like you don't need to remember kind of like the benefits and the option to create a FastKey. If I click on create a FastKey now, the first thing that prompts here is my password manager. So one password is already telling me, hey, look at that. You can save FastKeys within one password, right? And I can save them to my account, right? It automatically knows that my email. It put this icon to identify there is a FastKey and I can click on save. And as easy as that, I'm logged in. I'm automatically logged in into the Auth0 dashboard. So no need of password. I never registered a password. So the only way now to log in is through my FastKey. And now if I click on try connection again, the moment I click on try connection, and I see the Auth0 screen, you can see here on the top right, one password already knows. And this is not a one password feature. This is a FastKey feature because FastKeys are discoverable connections. That means that when you're on a website, you can ask the relying party if you already have an account for it. And in this case, we do. And it automatically triggers either the one password or keychain or whatever.

A device or service that you're using to register your FastKeys, it's going to automatically ask you to log in. And it is as easy as to click now sign in here with my one password to be automatically logged in. No need to put my email, no need to do anything. It automatically knows that I have an account and it automatically prompts me to log in. So it is super easy. It is fantastic. And again, it is the same process whether I'm using one password or whether I'm using any other device. Like, for example, I can use my UBIKEY, which is this hardware key that I have.

Yes, so the workshop will be recorded and we will share it afterwards. Thanks for joining. So again, we can now try connection. And if I wanted to, I could sign up, and I could sign up with a new email address. You continue. I'm going to create a FastKey, but I don't want to use my one password. So I'm going to use this. I can hear that triggers the default options. So in this case, I ignored one password. And now I have these different options because I'm on a Mac. I can create a FastKey using iCloud Keychain, and that will be synced with all my Apple devices. I can use a phone, tablet or security key. This is a very interesting option. And we will see that later. Or I can use my Chrome profile. And in that case, my data will be storing my Chrome data and sync with my Google account. I'm going to choose now to use a phone, tablet or security key. And when I do that, it's going to have a QR code. Yeah, so we're going to receive an email. I'm going to come back in a minute. So we see that QR code. And now I should be able to take my iPhone or any other Google option, and I can scan this QR code and trigger iCloud chain on my phone. And instead of using the iCloud chain, I can use my iPhone. I can scan it on my device. Or for example, if I'm on a Windows computer, I can use my phone to log in into my account. The same way I will do using Face ID directly on the computer, or if I'm accessing this website through the phone, I can go through this and scan the QR code. But even easier, I can also use my security key and access it with my security key. When I touch my security key, it has a button, which is my UBI key I showed before, and it asks me for a PIN. This is because I have a PIN set up for this. Not only does someone need to have access to my key, but they also need to know the PIN to log in. So I enter the PIN and touch again on the key. And now I'm logged in. And I don't even need a password manager, right? So I can use all the other options that I mentioned. In this case, I used this security key, which is a security key by UBI. Which is something I recommend. And I recommend, like I mentioned, having two of them in case you lose one, you don't lose access to your accounts. So what happened here is, yeah. So the application received all the information about the user. This is not all the information that Auth0 provides. This is just what we decided here to show on the screen. But Auth0 will also provide you with a field with a user status. That means that it will tell you if the user has been verified or not, if the email has been verified or not. In this case, we don't do anything about it. But if you want to enforce that all users that access your application are verified, you will have to do it on your side. Auth0 will authenticate the user as long as they match with the credentials. So that's something you can decide on your own. And all users will receive an email. And you can customize that email. It's in the branding section. Email templates. And so they will receive the typical verification email. Which here, where is this HTML you can customize. But it basically says, welcome, and then confirm your account. That there's a link and you click on that link and you confirm. Once you confirm, the next time the user logs in, it's going to have that field. I think it's called email validated or something like that. It's pretty obvious when you read about it. And it's going to have that in too. Then you decide what to do with that information on your own application. So yeah, email confirmation, same as always. That's why we also require an email in order to set up an account. Using past keys, technically you don't need an email.

But for now, we require an email for all users to authenticate through this method. Yes, you can use your smartphone. If you are on your laptop, you can scan that QR code that I mentioned. And use your smartphone to authenticate. And that automatically authenticates you in this method. And that automatically authenticates you in the laptop. Or if you are on your phone and you access that website through the phone, you do that automatically because you already have iCloud chain or the equivalent. And so you can use your smartphone, you can use a YubiKey. Or you can use services like iCloud chain, support past keys now, Google Chrome. So if you are using Google Chrome, linked to a Google account, you can save those past keys in your Google account. Or you can use a password manager like 1Password. And one of the good things about 1Password, right? Let's say I go here now into Auth0. And I look for my user that I just created, which is this one here. We can see that I have, so my email got registered in my 1Password account. Perhaps this is small to see, but I can't zoom in. I didn't know that. So I have here my, and then it stores my past key. And even if someone, I'm not trained and I'm a user who doesn't know what a past key is, and I'm so confused. And then someone from tech support calls me and asks me, I need your password because I need to access your account to fix whatever problem you're having, right? You know, it's a typical scam that happens in how hackers normally get access to information. Even if I wanted to, it is impossible for me to recover that past key. There's no action I can do to see that past key, to give that to an attacker. So it doesn't leave your device. It is safe. My cloud chain, the same thing. It will not let you see your past key. And in Google, I believe that's the same thing. So this is great, right? Because even if you don't know what you're doing and you are confused when someone calls you and tries to get your information, you cannot even provide that. You don't have even the option to provide that to attackers. It is fantastic. I don't know if that's better. So now I'm quite zoomed in. And I don't know why. Normally on Zoom, I'm quite far and there's a lot of space here on the side. And today I'm very close. So I'm not sure, Zoom being Zoom, I guess. I don't use it so much. So I'm not sure how well that works. Okay, so let me see. Oh, yes, yes, the banks. Yes, authenticating to banks is really painful. And I don't expect that we're going to see past keys in banks anytime soon. Because normally, the ones that should be the safest, they are usually the latest to implement new tech. For a reason, I guess. But yes, I would love to see that. Like right now, I need, like, for my bank, I use Deutsche Bank and it's so annoying because I need to know my account number. Who remembers that account number? I have no idea, right? I need to know my account number, my branch. I need to know my PIN. And then I need to know, I don't know, something else. And then on top of that, I need something called a TAN, which is a bad QR code that I need to scan on my phone. I never log in into my bank. If I log out of there, I'm months without knowing my bank statements because it's just so painful. Yes, past keys are stored somewhere. So they can be stored on a physical device, like a Yubicoke key, on your phone, on iCloud chain, on your Google account. So they need to be stored somewhere. It is still technically using your mobile data. So that's if you decide to sync them. So you can decide to use iCloud chain, for example, and not sync iCloud chain with the cloud. And in that case, we'll not use mobile data. The only mobile data transfers are going to be between you and the site you are trying to log in. For obvious reasons, you still need to transfer information. But there is no mobile data that is required to retrieve the key because the key will be stored in your device. Now, there will be a syncing process if you decide to sync that with the cloud, but that's completely up to you. So you have full control. And that's kind of the nice thing about it. I personally, now I'm using 1Password for some of my transactions. So I can use my passkeys. But I don't like that option so much. And I'm thinking of getting some other YubiKeys and only use the YubiKeys. I know it's a little bit tricky to use, like, always the physical device to do that. But now that the iPhone has USB-C and I have an iPhone, I can just plug the key to the USB-C and set up NFC, and it just works.

The other option is to use NFC, which this does also support, but it's a little bit more cumbersome. And one of the reasons why I don't like so much 1Password or other password managers to kind of, like, keep my passkeys information is the fact that I'm sharing my private keys. And I like the idea of my private keys remaining local. That's just me, maybe just a freak, when it comes to security, but I try to be as safe as possible. So, yeah, I'm seriously considering that option of using hardware keys. I like iCloud Chain a lot. It is very safe, the way they implemented it, because it always requires you to use, kind of like your face ID or like your touch ID. It's convenient, it's easy. But not all my devices are Apple devices. And so it becomes annoying when I use iCloud Chain. And I think iCloud Chain, and then I go to my Linux machine, and oops, I don't have access to any of my passkeys or any of my passwords. Apple makes that a little bit ugly. But if you're always in the Apple ecosystem, that's fantastic. And then you also have the option to use the Google account to sign them. But again, the same issue. If you're in a place where you don't have your Google account, then it becomes cumbersome. And I think more solutions will come, like other password managers are now supporting it. So I think the landscape is going to change where you can store and where you cannot store and what are the safest methods. I personally like iCloud Chain, the Google account, and the hardware keys. But that's up to each other's preferences. Everything is possible with passkeys. It is fantastic. It is pretty good. It is a really nice technology. I'm really looking forward to seeing more people going into passkeys. And you can do that with your Google account. I believe if you do a Google passkey, there's an address that you can use to log in with your passkeys, somewhere in your Google account. Here, create a passkey with your account. So, safety.google.com slash authentication. This is also in your Google account. You can create passkeys for your Google account. So Google is promoting this heavily. Apple is promoting this also quite strongly. So we will see adoption happening. It's just going to take some time, but we will see adoption slowly happening as this giant push on passkeys.

All right. So, let's continue. So now we have made a lot of progress, right? So we already tested everything in the Auth0 dashboard. See that everything works with passkeys. We already have a database connection here with Auth0. So we are pretty much good to go to start coding.

So yeah, we're going to start the fun part now. So we're going to create a Next.js application. And there is no boilerplate. I really want to show how easy it is to do everything from scratch. Most of the code that we are going to write today is going to be CSS. But we're going to go through it very fast, because I don't want to bother anybody with those details. But yeah, let's get started.

So I'm going to move into my... I've used Remix, yes. And I'm waiting on the new Remix version, which is going to have several components and all of that because I'm not very happy with the way Next.js implemented all this stuff, and I'm hoping to see Remix going on a better path. So I don't know. I don't know. I have a lot of expectations. I really would like to see how that looks like. But yeah, I used Remix in the past, and I enjoy it.

So... All right, so I'm going to create a new Next.js project here on my laptop. So... I'm going to make this bigger so it's easier to see. And I'm going to be following the instructions that are here on the Create Your Next Application in the workshop link. And I'm going to simply do this npx createNextApp to create a new application with the latest versions. I'm okay to proceed.

Application project name. Let's call it my awesome login. You can call it whatever you want. We're going to use TypeScript. We're going to use ESLint. We don't want Tailwind CSS. I love Tailwind. This breaks my heart, but I don't want everybody copying or calling a ton of HTML just because of Tailwind class names. We're going to simplify that by saying no. Source directory. No, I guess. This is totally up to you. Let's see what the recommendation here was. Okay, we said no. That's up to you. That's really no need. And we're going to use AppRouter because it's this recommended way. So we're going to say yes. But everything that we do will support AppRouter. And the old pages router. Just the code will be a little bit different. Or where you create your code will be a little bit different. But it's going to be the same thing. And we don't need to customize the default import alias. All right. So now we wait for npm to do its thing. Yeah. Hopefully it doesn't take forever. You never know with npm.

All right. So going back a little bit to the workshop while that runs. We have our application. We have our NestJS application running. Yep. So let's just test that out. Yeah, I think that's good. Kind of. All right. So it created my app in a new folder. Oh my terminal. I don't know what happened to my terminal. I think every time I was trying to increment the font size. It was incremented my window size. It's huge. All right. So there we go. So now we are in the project. And yeah, we can see all the typical files. It creates the.kit folder. It creates the github. It does all the stuff automatically for us. NestJS loves its magic. So it tries to do everything as magical as possible. So let's open VS Code. Because everybody loves it. And let's open a terminal in VS Code. So we have everything handy. And if we do now npm render. It will render the data, you have your NestJS up and running. So it should be running on localhost 3000. And you will see this nice Vercel page. With a default template. It's time to get our hands into some configurations.

And then adding some more code. All right. Let's go back to the tutorial or tutorial. Go back to the workshop file here. And then let's continue to create an Auth0 application. So we are going to go back now to the Auth0 dashboard. We can use this link or we can use the window that we have already open.

And one thing that is important to understand with Auth0. Is that when we created our account. We created a tenant. And a tenant will have multiple applications, right? So we said that normally the tenant will reflect to like. Your development environment. And you will have like organization. Or group of applications. That's completely up to you. Normally, I like to use it as an organization. Similar to like GitHub organizations. And then inside that I will have like multiple applications. That belong together.

And the applications, if you go to applications. Menu. Applications. Within Auth0. There is an application that is created by default. For us. And this is kind of like an important application. And it's not one that we should use. So we are going to create a new one. For the purposes of this next JS app. I'm going to hit. Here on create application. On the top. Right side button. And I need to give it a name. And I think we call it my awesome login. The name doesn't need to be the same. So we can call it whatever we want. But I'm going to. Keep it. With the same name as the project. Oh my awesome login I think. I'm going to keep it with a similar name. So I can relate my Auth0 applications. With my code base. And there's no confusion in the future. In the future about it. And then I'll see those asking me OK. What type of application are you going to create? Then we have native applications. Like for example it could be a react native app. It could be a desktop. So any mobile application or desktop application. So we are native for example. A single page single page application web apps. Like if you're using remix or just simply create react app. So that doesn't exist anymore. But like any SPA with react would be this option. And then we have regular web applications. Which are the traditional HTML CSS plus JavaScript running on the browser. Plus some server side code. And that's kind of like what next JS is. So we're going to select web applications for us. And then you have machine to machine applications. And this is for example if you're running like microservices. You need two services talking to each other. Or if you're running a terminal application. And you want your terminal application to log into your API. Then you will use machine to machine applications. In our case regular web applications for any next JS app. We're going to click create. OK so when you create an application.

Auth0 will ask you OK so what technology are you going to use? And you can say here. Or you can look at your common technologies here. Or you can also look for example next. And I have the option here. And I can click on that. And it will automatically suggest me a guide. On how to integrate Auth0 for that particular technology. You can download a sample code. Or you can do it in your own application. That's up to you. So we are going to go quickly through the steps. But we're going to follow the workshop. Because I like it more. I wrote it. I'm more familiar with it. Alright so that's a quick start. When you create an application. But there are multiple tabs. The second tab corresponds to the settings. And this is where we need to customize some things. When we go into the settings. We are going to learn a few things about our application. Like what is the name of the application. What is the Auth0 domain? What is the client ID for your application? This is going to be unique for each app. And also a client secret. And we're going to need these three pieces of information. We are going to need in our application. In order to connect Auth0 with your NetJS. And we are also going to need if we scroll down. I mean there are things like the logo that you can customize. You can also always change your application type. If that's what you decide to do. But under this section. Application URIs. We need to set up two things. Which are the allowed callback URLs. And the allowed logout URLs. These are the URLs from which Auth0. Will accept requests from. So in our case we are hosting our application in localhost. So that's what we are going to set up. And our callback URL will look something like this. And we are going to have the user. Will look something like this. I'm going to paste it here on the window. I'm going to make it bigger so it's easier to see. But it is basically localhost port. Slash API. Slash Auth. Slash callback. This is something that we decide or that we like to do. We are going to need an API to handle the callbacks. So we put it in the API folder for NetJS. This is kind of like a NetJS requirement. If you want to say so. But if you want to say routes. That will be totally different. And then we decide to group all the Auth0 APIs that we need. Inside the OAuth folder. And in particular we are interested in a callback. And we are going to need multiple of these APIs. For Auth0. The Auth0 SDK will register them automatically for us. So we don't need to build all of them. Like it was in the case of the manual application option. We saw that in the presentation at the beginning. You can add multiple values here. Like you can separate by commas. And this is something that I normally recommend. That you add your localhost.

And you also add your 127.0.0.1. That way no matter how you enter into your application in your browser. Both ways will work. Only for development. In the case of production you will have your product.com. So that's what goes inside the callback URLs.

And we also need to add the allowed logout URLs. Which is very similar. This tells Auth0 what URLs are you allowed to log out from. In our case localhost 3000. There's no need for APIs or anything like that. And also we are going to use the 127.0.0.1. There's no need to add both of them. Like I said I like to add both of them. Just because sometimes I type localhost. Sometimes I type 127. And then you start getting rejections from Auth0. Because you are using one or the other. I normally register both of them and then I'm safe. Alright. And yeah. So with that we are good. Now you can scroll to the bottom of the page. There's a lot of other stuff you can customize here. With Auth0. But for now we are going to scroll down all the way to the bottom. Until the save changes button is here. We are going to save changes. And now we can use our localhost to connect to Auth0. That's fantastic.

On the Auth0 side we are pretty good. There's one thing that we need to do now. Which is our application needs to be aware. Of Auth0. Right. It needs to know where to log in. What is that universal login screen leaving. And it needs to be able to decrypt the session. That Auth0 is going to create for us. Right. And to do all of that we are going to need to copy all this data from here. Domain, client ID, and client secret. Into our application. So we are going to create a.env file. Now if you go into the workshop page. We provide a form to generate the.env file for you. It is quite easy. So if you don't want to use the form. You can do that directly in your code editor. I'm going to use the form for now. I'm going to copy my domain. And I'm going to paste it here where it says Auth0 domain. I'm going to copy the client ID. And paste it here where it says client ID. And then I'm going to scroll down a little bit more. And it asks me to run this node command. This is because we are going to create a session in Next.js. And in order for Next.js to create a session. It requires a secret key. This is something just for our application. It's not for Auth0. It's just for our application to sign the cookies. A good way to create this code. Is to run this command. That is here in your terminal. I'm going to go back to Visual Studio. I'm actually going to do it in my terminal because. I have it here open. And it just generates this random string. You copy that.

And then you paste it there. What it says here. Auth0 Next.js Secret Key. And this is what we are going to use to sign the cookie. Again, it's only for your Next.js app.

All right, and now we need to create a.env.local file. And, yeah, we're going to do that directly here in Visual Studio. There we go. And we're going to copy. All these values. And we're going to paste them here. All right, so this is what the.env file looks like. Like I said, you can build this yourself. You don't need to use the form in the workshop. But you basically need to enter your Auth0 Secret. This is what we generated with a Node command. You can also replace this with la la la if you want. Not always. When I'm in production I use something like this. When I'm just at home I just made up something myself. I need to be quick if I don't remember the command. It also sets up... Yes, you need to add it to the Git Input. Yes. I think normally this is done. Yeah, so this is normally done when you call it.local. In your Git application. But if you are not using, like, the create Next tab, you have to do it manually. So you set up your Auth0 base URL. Which is what you use to run your application, localhost, your own domain. Your Auth0 tenant information, the domain, the client ID, and there's also an Auth0 client secret. And this is something we didn't add in that form. Like if you look at this form, we never introduced this secret. And this is because your secret is the most important value in your Auth0 application. If someone gets access to your secret, they can get access to... They can get access to... They can get your same access to the application as you have. So they will be able to create users to create an application impersonating you. So that's not something you want to give up. And that's why we didn't put it in this form. Because even though this form, it only works locally. It doesn't send the information anywhere. We don't want you... to give you the feeling that you should be copying and pasting this into any website. So we don't do that. You go into your Auth0 web, where it says basic information. You go to your client secret. You copy. And when you're not sharing your screen, you paste. Now everybody close their eyes. And yes. So I saved that and now I close the file and no one needs to see that again. If someone copied, you were fast enough. Maybe you can access until the end of the workshop. And I delete that secret. But now we already have our Auth0 configuration in our.env.local file.

What comes next is to install the Auth0 SDK. So one of the nice things about Auth0 is that we provide SDK for most major frameworks. And if you're working with JavaScript, we have SDKs for Vue. We have SDKs for React. We have SDKs for Angular. We have SDKs for Next. So now I think we are working on an SDK for Svelte. Then we have SDKs for vanilla JavaScript. So if we don't support your framework, you can also use the vanilla JavaScript. And that will work in most scenarios too. And if we don't work with JavaScript, we can provide frameworks for Python. I think there's.NET. There's Java. So there are a lot of other frameworks that we provide direct support to.

Even if you're on mobile, there are frameworks for React Native. For example, for Android. Native Android, Native iOS, Flutter. So no matter what you're building, you're going to have an Auth0 SDK that is going to work for you. So if you start as a web application, then you need a mobile app, and you're using Auth0, there's no issue with that. With some other providers, you're restricted to maybe one framework like React or something like that. In this case, you have plenty of options to choose as your application scale. And I should have said all that while installing my package. But yeah, things happen in real life. So I'm going to do that now. I'm going to install NPM install. The application is called Auth0. So you can copy that from the workshop. Yeah, look at that. That was very fast. All right, so we have now our Next.js SDK installed. And we can start working on code. So remember that when we went into the settings, we specified in our application an API. And this API registers a callback. We're going to have more than one. And now Auth0 needs to know where these routes are going to leave. Because it's going to create all of these endpoints automatically for us. We just need to tell him where these endpoints are going to leave. And to do that, we created this command. We have this short command that I'm going to run it very quickly and I'm going to explain what it's doing. Basically creating a folder structure inside my app directory. This is where all the application code is hosted in an Next.js application. We have the API folder. And under that, we have an Auth folder. This is just what I decided to call it. You can call this whatever you want. But because all the authentication endpoints are going to be living in this folder, I just call it Auth. Easy to understand. And then we call this endpoint or this folder here that has a particular name, right? It has this name between square brackets. And it says Auth0. This is a dynamic route within Next.js. And this route is basically a fallback. It allows me to capture everything that happens in slash API, slash Auth, slash. It's going to fall under this route.ts file, no matter which name it is. So it could be callback, it could be login, it could be signup, everything is going to fall into this route.ts and it's going to execute the same code no matter what that endpoint is. And this is particularly important. Because in one place, we can define all the Auth0 methods that we want. So what is the code that belongs there? It is simply this code that we have here, which is actually an import and one line of code exporting this handle of... I'm going to copy that and I'm going to paste it in here. So hopefully this is big enough for everybody to see. But we have, again, two lines of code and simply one line of code exporting this function handle of that we import from the Auth0 SDK. And this handle of is going to automatically register our login endpoint, our logout endpoint and our callback endpoint. And we'll see why that's important. So now with that done, so, yeah. So if you go through the workflow tutorial or the workshop tutorial, you'll see that this is going to automatically for us login the callback, which after logging in, it goes to the callback to be at the local session or the local next session, logout endpoint, and also slash auth slash me to get information about the user. All right. So what we can do now is we can do npm rundev again to launch our server again. If you're not running it anymore, and we're going to go back to our browser and we're going to refresh on that screen and everything will look the same. But if on my URL, I now type slash API slash auth slash login, right? And I press enter. I'm going to paste that URL also here in the chat. If I press now enter there, this API endpoint will redirect me directly to my Auth0 account. Which in this case happened that I was already logged in. So it automatically tells me, are you authorizing this app? Right? To your account with my email, this is the name of my app. Right? And this account will request access to your profile. So means that it's going to get access to your profile and your email information. You can make the route localhost 3000 slash login. Though it's going to it's going to give you it's going to give you problems with Next.js mapping that dynamic route. So you'll have you'll have to create individual routes for slash login slash sign up slash blah and then copy the same code in all of these places. But it's going to I would recommend to at least put it inside a folder. You can always you can always have a slash login and then point our direction to the API call. And I think that will be the easiest way to do that. Oh, yeah. Yeah. So technically you can do 3000 slash login, but with Next.js it may become like a little bit painful. If you want to set up the SDK and all the calls there, my suggestion will be to have at least the API folder and then yeah, it is Next.js.

It is the way dynamic routes work, right? If you handle the dynamic routes then you start having like a lot of dependencies you need to think about. So I don't recommend that. But at least having a folder and then and the slash API slash path coming actually from a legacy Next.js where the API folder was a requirement now is not anymore a requirement. So you have a little bit more flexibility, but before Next.js 14 it used to be a requirement or before Next.js 13.4 it used to be a requirement to have the slash API for this kind of scenario. So now with the newer version that's not required anymore, but I still don't recommend. All right. So, this is traditional OAuth authentication or consent form where you can deny or accept. In my case, I'm going to accept. And when I accept Auth0 redirects back to my callback. My callback process all that information from the log-in automatically and I'm logged in. And I get redirected back to my home page. Now I don't see any I cannot because the callback redirects me automatically so you don't really see anything. What I can do is I can go to logout. All right, so I just logged out and I can open my network tab and preserve the logs. We see everything that is happening and I'm going to go back to the login. Right, so we are in Auth0. I'm going to clear this again. And I'm going to log in using my key. So for instance, I log in and there is no key value other than the log-in. So we see the form because now I logged in with test two instead of three. This only happens the first time and you can hide this form so you can have it in a way where this form is not present at all in case of building your own app. Let me go back to the log-in. So now if I look into the callback, maybe this is going to be hard to see. So now in the network tab you can see the callback call here which passes the session data and then the callback will automatically perform all the validations and create a local session. So if you take a look into the cookies folder here, the callback is setting two cookies. So it's creating the verification cookie and it's adding this app session cookie. And this app session cookie will contain information about the session. We'll see that in a minute. But this is the callback. After the callback process information it automatically redirects it to the home screen or you can for example when you call your login end point you can say return to and then pass the URL where you want the users to be redirected to after logging in. If I do profile. Now I was already logged in so everything happens automatically. It redirects me to the profile and the callback will handle that. There are ways to customize that and you can pass an object here and you can override the callback behavior with properties. It's documented on the GitHub page for the next SDK. By default you get all the information directly to the page. All right. So we are already logged in but there's nothing in the application that tells us we are logged in. Because I never changed the HTML template. So I'm going to do that next. If I go back now to the workshop it will walk us through the process of changing the templates. Now since many of you are not familiar with next.js, next.js version 13.4 onwards introduced what's called the app router. It's making use of server components and client components and we are going to learn about each of these things. We will start with the client side. On the client side of things we will use providers and context. So you can follow the link here in the tutorial. So let me copy the tutorial link here. That contains all the information that you need to be able to use next.js and the instructions and all of that. I'm going to push that to GitHub and I'm going to share with all of you after the workshop. Sometimes we take different paths depending on the questions and all of that. So you can go to the next.js SDK code. You have this link to GitHub for the SDK. All right. So continuing we were here. So we'll use context. We will use the context. And it will put all the information about the session on the context provider and then you can access that information in your application. But in order to do so, you need to register your provider in your application. And the best place to do that in the context provider is in the client. So they will always run in the browser. So we are safe to put providers in here or context API in here. And yeah. So we're going to add them and we can use it throughout the application as long as we're using client components. This is not a prerequisite. But if you're rendering a client component, then we can access that information through the provider. So you can either copy and paste this whole code, but really the only thing we changed is we are importing the user provider from the SDK. Outsider next. JS. And then you need to add this user provider and we can use this as a user provider. So we're going to add this as a user provider and we can consume this user information in other areas or in other pages in the application.

And we're going to use that next. So I'm going to continue here and I'm going to paste this in. So I'm going to copy this template that we have here and I'm going to paste it here in the browser and we're going to go through the code and try to understand what we did. So the first thing we changed besides the layout is we added this user page. So the user page is loaded but the page loads for the first time and the session is loaded. So you can use that to show your typical screener or things like that. So we get the user information and then the user can be of the type user profile or undefined. If it's an end user profile we can use the user information and we can show the user profile and we can show the user profile. So if the user profile is undefined we can show the user profile and if the user profile is defined we can show the user profile. So we get the user profile and we can show the user profile. So when we get the user profile we show the user profile. So I can go to my application and I refresh. We are already logged in. So I see my logout button and I see hi and my email. I never enter a name and right now my name defaults to my email and my email defaults to my email. If you are using a social provider it will expose the image of the social provider and if you don't use a social provider you will use atar. In my case this email I just made up so it doesn't exist. I just put my second name. So I take my email and kind of like that. You can change all of that. Also like when you create a user profile page. So now if I logout I can click on the logout button and have the application refresh and I can logout. And then I can logout. So I can sign in and when I click sign in now because I already accepted the flow for this user it doesn't ask me and it automatically redirects me to the application where I'm already logged in. So I can copy this three values that we mentioned. Domain. Client secret. In addition to that you need to install the next SDK that works for your framework. And then you simply need to implement this API calls in the code. And when we needed to work on our UI we needed to invest more in code by using the hook use user and also by using the conditionals of the user to render the different parts of the screen. So that's yeah. That's it. I don't have any questions so far. Like on the integration how it has been so far. I think it's pretty straightforward. This is what I normally cover on the workshop. We can go through some questions. And I can also further add some things to this. Like capturing the user experience in the web. So I have a question here which is does Okta use our user data? The answer is no. We are not in the business of selling your data. We will charge you if you exceed the free plan or if you use one of our advanced features. You can see the link to the website. So I will show you some of the data. So let's see. So we have one thing that we have. So we have a database connection. So the database connection is a database connection. So we have a database connection that we are using. For example, I have users, meaning they are saved in the database. And I also have users that are logged in using social providers like for example you can click on custom database. This is not a free option. But if you want to, you can say use my own database. And when you enable this, okay, so you can use passcodes to use your own database yet. But if you enable this, when you're not using data, you can click on custom database. And let me create a new database. I'm going to create custom and I'm going to click create. You can have as many databases as you want. And you can assign them to your database. And you can assign them to your database. And the other option is to use Mongo DB. And you can use Mongo DB. You can install Mongo DB. This is a very simple way to install Mongo DB. So we will start using this Mongo DB database instead. We decided to do JavaScript for this with templates because it can be as creative as you want. So you can use this database like Mongo DB instead of the old database. You have full control. That's pretty good.

That's pretty good. Another option, if one day you decide to leave old Sera, you can take the database with you. You can import the database into any other service you choose to. You are not locked with this vendor in particular. You can take your data with you. Something you cannot with some of the other providers. I think that's very important. We don't use your data at all. We don't use your data at all. You always have full control. Very important question. Thanks. Any other questions related to old Sera?

Meanwhile, another very important question I get asked is how much can we customize? The answer is you can fully customize it. You can customize it. You can customize it to the best of your ability. You can customize it to the best of your ability. You can customize it. On the free plan, you can go into branding, universal login, and you can choose to change the logo, the primary color, and the background color. You also have advanced customization options. Which allows you to customize every button with colors, different colors. You can change the fonts, the borders, the widget itself, the position at the left, the logo at the left, the right, where do you want the social buttons, you want them on top, or bottom. You can change the color of the logo. You can change the font. You can change the color, the font, the text, the markers, the fonts, and the widget, and the text. There is a free plan, and if you want to write your own HTML, you insert the widget, which is the small rectangle, but other than that you have free control. That's the maximum level of customization that you have.

Another question we have here is to implement the task keys in an executable or in an API? The answer is yes, you can do that. If you want to do that on your own, you can use this project. I think it was called simple web of n. dev. In an XJS application, or in any JavaScript application, they have examples on how you can do that on the browser and on the server to do that yourself. One of the things I said at the beginning, this is a great project, it's great, it works, it's all great. It's a great project. It's an easy project. It's an easy project. You can do it on the web, it's an easy project. If you want to do that, this is an easy project. If you are experienced enough to be implemented this, this is a good option. This will provide you only web authentication. Then you need to think, maybe not all of my users will use that. Maybe they will use social connections. Then you will have a solution that is out of the shelf. You get it, you forget about it and you go and build your features. It comes with a price tag. There's a free plan and it's generous. As you scale, it will come with a cost. You always need to balance the cost of implementing yourself. It's not the only solution in the market. But it is one of the most complete features. I recommend you try it out. You can integrate and you will see the value added. We talk about the price tag. We also have enterprise connections, let's say, scaling. This is a typical use case. You build your AI tool. At the beginning, you have users that are going to sign up on their own and start using your app. Your app is doing fantastic. I don't want every user to sign up, but I want to sign up as an organization plan and give access to my users. And in that comes in our enterprise connection where you can have Google workspace. So you can connect to any provider and we have the option to use OAuth two. We support that. Yeah, so there is us for the protocol. Yeah, so we use OAuth two. That will belong inside the social providers, right? So all zero by one. And as you can see, it is basically the same protocol. But as it implements the protocol, it can connect with any OAuth two provider. If you ask me, I don't know them by memory, but there is a lot of them that will work with different types of settings. But if you're using social connections, we support all the OAuth two providers. You will connect to them and start logging in with the client. Also as I was saying, you have enterprise service to the client.

You can connect to that client. So we provide these kind of options that will help you scale without implementing yourself each one of these options as they happen. When anything happens, you can give us a call. We activate it for you. The code that you have is going to be pretty much the same. The only thing that will change is the configuration. It is pretty powerful as you grow in different options. It will allow you to adapt to different scenarios.

If you are growing, you will have these requirements. It is natural. We see that a lot. We also offer other passwordless flows. We don't really highly recommend them anymore. We now recommend that you use them as a way to have a secure experience. Are there any other questions? I can keep talking about it all day. We have plenty of features. Are there any other questions about code? If you have a particular framework, like the SDK, the code is built in. You can use it as a framework. We have a developer center. There's a lot of information for developers in general. One of the sessions I like here is the regular web applications. If you click one of them, you have the different frameworks. If I click single page application, we have standalone applications. For example, Angular, React, JavaScript. I'm not very familiar with Angular, but there's different options. For React, we have multiple options. We have React without using React router. We have on deploying React apps to Vercel. Vue.js. There are different things. If you click on any of them, you get a full guide on how to set up everything. Very similar to how we are doing in Angular. If you click on the other features, you have a list of features. You can add a list of features. You can add whatever you want. You can add a list of features to Vercel. This means log-in and log-out. Or control where you're going to define roles in your application and we have access to different things. We have examples we are building with fine grained authorization. This is coming soon. It's a full version. You can have folders for example. And share the file or the folder. If you share the folder, you can have folders or be as creative as you want. For now we have these two options in examples. If you select root-based access control, you can use react, react 18, TypeScript, React router, and then I choose my backend framework. It doesn't need to be JavaScript. I can say I want my API to be fast API. I select fast API. I click continue. And now I get a tutorial on how to build exactly that. It's a tutorial with React router that connects to an API and that API is running fast API. It's going to guide you through all the steps. Setting up the front-end application, setting up the settings, and setting up the API with all its brushes. With sample code. And this belongs into developer. The link that I shared on the screen. Yeah. There we go. Developer. The link we have there on the screen. If not, I can also give you time back. I think it has been an incredible session. At least I had fun. We learned a lot today. I hope you try it at home. That is really not a big commitment there. As you can see, it was quite easy to set it up. If you have any questions, any technical issues, or anything at all, feel free to reach out to me on social media. On Twitter, LinkedIn, and Instagram. You can also scan the QR code there to see other ways to connect with me. I'll also provide the link to the workshop on social media in case you missed that. I think that's pretty much on my side. I hope to connect with some of you. I hope you all had fun and learned something new. Hopefully to hear some of your feedback. Thanks, everybody. It has been fantastic. Thanks a lot for joining.