 Hello everyone, welcome to this month's IMT and security meetup. Thanks for everyone who has tuned in and I'm going to introduce myself. I'm Pradipa, I'm a developer advocate at Okta and today I'm joined by Dyson. Hi everyone. Hi Pradipa, how's it going today? It's good, it's going good. I think I'm expecting more people to join but yeah, it's time we get started. How's your day? Well, it's still hot in Japan. Yeah, by the way, hey everyone, my name is Dyson. I'm based in Tokyo, Japan. I'm a principal developer advocate at Okta and in Japan, it's still hot. You know, we have like a 30 degrees today. You know, it's already in September but it's still hot, how about you? It's always hot in Singapore, so I can't complain. Yeah, so we are from the hottest region. Okay, moving on. So this meetup is sponsored by Okta. If you'd like to co-host or co-host this meetup, feel free to reach out to me via email. We are looking for volunteers, organisers around this meetup. Also we have a strict code of conduct. So in short, treat us how we want it to be treated. If you see any violations or any other subject or witness of code of conduct, reach out via the meetup of my set or reach out to me via my social. You know, just send an email to me. We'll make sure that we take necessary action. You also have a privacy policy. If you want to know how we are using the data being shared, how you're signing up, please read this privacy policy. And yeah, let's move on. As with any meetups, we are always looking for speakers. So if you're interested in giving a talk or if you wanted to give a demo of whatever you're working on, be it live production or your own personal projects, please submit your title and abstract. We can just put it there and then whenever you are convenient and available, we can invite you to join this meetup. We can also do it online. And also we are planning to do hybrid. If you're in Singapore, we can also do it in person talks. So feel free to reach out to me and some of this talk. And what do we have next? This is our zero index newsletter. All the dev rails, what we are doing, what all the events we are attending, what's happening in our zero. All this updates comes from this newsletter. If you want to know more about anti-insecurity, what's happening in our zero world, what's happening in the anti-world, where our dev rails are, do sign up for this newsletter. You'll get a belt of information. If you don't like it, unsubscribe it, but do see what's there in it. And let's move on. I have one question. Whenever you have questions, you please put it in your live stream chat. So I can consolidate it and without disturbing the talk, I can answer the question at the end of the talk, but you don't have to hesitate waiting for the session to complete and then post a talk. So show the questions right away. No questions are stupid. All the questions we are trying to answer. We are trying to educate and create awareness about anti-insecurity. That's the whole purpose of this meetup. Feel free to ask questions. We are here to answer. And I'm going to introduce the speaker. So this is our meat of the meetup. So our first talk is going to be enhancing Ethereum keypad generation. And Shavas is going to see how he can leverage odd zero and with three odd for security. I'm going to ask Shavas what is he doing in this and what his passion are. Hey, Shavas. Hey, everyone. Hi, thanks for having me. Thanks, Pradeep. This is one of the important and also overwhelming for me because I love both of the product. Like I work for Web3R as a developer relations. And I've been odd zero ambassador for a very, very long time. I think it's from the start, I would say. And when you use both of the product which you love, I think that's what is going to be crazy. The moment I came here, we spin up the guide. We did a lot of things with odd zero. And in this talk, what we'll see is like how we can use the odd zero's modern identity and leverage those to get the Ethereum private keypair, which is more secure and like how Web3R is doing the key management and everything around that. So yeah, can't wait to start the talk. Thank you. I have one thing you would love to really love to meet up. What's your personal hobby apart from being a staying away from the computer? What are you doing? I think if you ask my Web3R colleagues, they would say definitely cooking. And I'm more famous for my Briani basically. So yes, I also not just Web3R colleagues, but anyone also me. I prefer when I'm not doing coding, I prefer tinkering around in kitchen and helping my wife, if not like hopefully, but it's something and there will be someday where I just do the whole cooking. So yes, I love doing cooking. Nice, nice. Yeah, I'm going to do just this up here and then get you on with it. Thank you so much for coming and doing a talk. Sure, definitely. Let's start when the slides are shown. Looks like slides are here. Hello everyone. Welcome to this talk where I'm going to talk about how, you know, enhancing how we are using or leveraging odd zero and Web3R to, not in terms of accessibility and security, but also enhancing the 3M key pair generation. So let's get started. My name is Mohammad Shahbaz Alam. If you want to follow me, you can follow me at mdsbzalam. Twitter for any queries around odd zero or Web3R or in general about security. So let's get started on the talk. So as you, if you have heard about Web3 and anything about wallets and what's key in the Web3, so like these are some of the important, you know, issues like people misplace their keys and lost, basically Web3, everything is associated with fun. So you have an address and that address has some funds. But it has something called seed phrases, which are very, very hard to remember. It's a very long, complex things. So one thing what is very much increasing is more about losing those keys and as the funds. Then there are high drop-offs to onboarding people to Web3 because of the use of seed phrase, because it needs to, people need to remember that, memorize that, maybe write it in a proper sequence and then when time comes, you need to input that like 16, 12 character, 12 words, 24 words depends on wallet to wallet. So this is something what we have seen the past as well like how Web2 login has been solved previously. If you remember there was like username and password, what Auth0 did is they brought in, oh yeah, this is a way to do the login with Web2. You don't have to worry about configuring all different applications at different places. Don't worry about your passwords and, you know, like username and password fields, that's also covered. So user intercept, login with SSO or login with Auth0, Smodal, and then start using that. That's the flow what people love in Web2. But when you talk about Web3's early days or still in Web3, there are wallets where there's a lot of steps to just onboard your users. They enter your app, they need to understand, oh, they need to have a wallet and what is wallet, Web3 wallet. Some wallet has to have like a wallet extension, browser extension, or some might need to have the wallet itself in the mobile, in the form of mobile app. Then they onboard into the application, set up the process, go through the seed phrases, and not just entering the seed phrases, they'll just, they need to remember and store it and then start using that, right? So what Web3.auth is doing is that they want to get rid of seed phrases and want to provide you similar experience. So what you see here is exactly Web2 experience, but behind the scene, there is Web3 activities, not just that, if there are existing users who have been initially onboarded to those wallets, they can still connect with Web3.auth this model. Like if you see at the bottom, there is like connect with wallet and it will allow you to connect with your existing wallet and maybe just use that particular wallet. So the flow remains same as Web2. Users interest the app, sign in with any of the favorite SSO, or they can sign in with email, SMS, or even with the external wallets. So in overview, what we have done is basically try to provide passwordless authentication for wallets so that people don't have to remember their passwords and seed phrases, which led us to enable the non-custodial key infrastructure for everyone. And this we have, till now, we have onboarded 800 plus dApps and wallets, 1200 million plus active wallets a month. And there are big enterprises and dApps who have been using us, like Fox, Mask Singer, Binance Wallet Extension is using us, trustwallet, chess.com, and there are many more which are trying to onboard a lot of users and reducing the frictions. So let's understand how and what happens at Web3.auth behind the scene and how we are non-custodial. So I'll talk about the right part of the diagram where it says where the OAuth login share, where if you see it as like an Auth0 login, this is one of the shares which is being derived from different, like nine nodes of Web3.auth run by different Auth networks providers and out of which the five nodes needs to be, you know, available to reconstruct the Auth share and there is a concept of like device share and backup share. So out of these three shares, you need at least two to reconstruct the private key and that's how we are achieving the private key based on the OAuth login. And when we come to the left-hand side where the whole architecture is laid upon and talks about how the whole flow works, basically if you are integrating Web3.auth SDK, what happens is that the front-end will initiate the login and we'll also see it in the demo app. I have made a cool demo app just for this talk where we'll go from different aspect of it. But let's say the front-end triggers the login and goes to Auth0 and as you know, Auth0 has various login providers available for you to configure and use through the Auth0 modal. Then you choose those login provider. In this case, let's say about Google and then the Google will relay data back to Auth0 and the best part of Auth0 is that they give you ID token and I'll talk more about ID token and how we are using ID token more in our development processes. So Auth0 gives us the ID token to Web3.auth. What happens here is the ID token which is again the OAuth login share. If you can remember this, this is exactly this. So the OAuth login share, what we do is we pass the ID token for validation and if you have not seen that Auth0 gives you tenant-based JWKS to verify the ID token's authenticity. So using that, what we do is verify whether the ID token is for the user who they say they are. Once they are authenticated, the whole process happens on the nodes and out of those five nodes are selected and then we get the private key share back to the OAuth share. This is just one share. Once we have this, we have another share which is like the device share which is let's say in your case could be a mobile device or a browser. Out of these two, the private key will be constructed and I'll show in the demo app like how a private key looks like. There is something called backup share or a two-factor auth share. This happens when a user wants to enable the two-factor authentication. They can have this factor set up in various ways. If time allows, I'll talk more about this but in GIST is that you can have it in the form of a backup phrase or it could be your second social organiser, second factor authenticator or your SMS or it could be just a password as well. So we'll see all these but for that, let's move on. So in this thing, this is going to be more of a hands-on one. What we would need is more of a dashboard from Web3.auth and dashboard from Auth0. So let's see it in action how this looks like. So this is Web3.auth. Once you sign up for this, you will see a dashboard which looks something like this. So what we need to create is more about a project and I already have a project. You can just simply create a project. There are different projects and products all about this. So I'm not going to configure all these. I already have this. What and how Auth0 is being used is in the form of custom authentication. I also have that which we are calling as a verifier so that we can verify the ID token being returned from Auth0 and it also does a lot of things with blockchain. So what is basically this is how one can create Auth0. Auth0's verifier is simply create a verifier, name whatever you want to name it. And from custom provider, we have a way, or in social login provider itself, one can do directly from Google, Facebook, Discord, Twitch. Also we have a special one with Auth0. If you do select Auth0 here, it gives you a list of authentication type which is already available on Auth0.dashcode. I'll show all of these. And even if one of the options is not shown here, one can do custom or others and just use the domain level or tenant level JWKS can be passed here. Or I mean, I will, here just the Auth0 domain can be passed here. And most of the thing and heavy lifting is done by Web3.org. So you don't have to worry about it. If you're referring more of the custom way, you can also configure that. So this is how we do. I'll show you about Auth0. So what we have done is selected Auth0. This is just a specific for Google, but using this one, we will also see the whole list of Modal, what Auth0 present. What we need is like Auth0 Clientary. Yes, this is one I'm exposing, but feel free to use this. This is just for a demo app. Auth0 is a client ID and domain. So how do we get that? We get that from Auth0's dashboard. If you don't have one, create on manage.auth0.com. So this cool thing about Auth0 is that I have like multiple things, one for development and product and how I manage it through the tenant, basically. So this is, I think, looks like it's a correct tenant. One has to just create an application. If you can see that I've created multiple applications around here. Let's talk about Web3.auth Grandma. So this is just a thing what we say at Web3.auth is the mascot. So you need Auth0's domain, tenant-level domain and the client ID, what you are seeing. So these two information goes here, the client ID and the domain. And this is something if the name says, what's the GWT Verifier ID? And I'll also share more. So this has the options of like sub or email or any custom. So what does this mean? So this means that what from the GWT token, if you see, if you know about GWT, it has payload. It has a lot of things like ISS, AUD, SUB, all those details, we'll also see it in action. So your private public key pair of Ethereum will be based on which particular ID based on. So this is going to be a unique one. So from a lot of GWT payloads it tends to be either it's best to have it with SUB which is the subject or the email of the user which is already most of the time present on the GWT payload. So we did SUB and then it's done. This will be into the production state, I mean publishing and then once it goes live things will look like like this. Basically, I'll show you in there, but the it does not just end here from the odd zero side. So we have plugged odd zero details the domain and client ID to web 3 odd. Then now we need to configure from configure for odd zero so that the redirect URL could be matched. So you just have to enter a loud call back URLs to like auth.web3r.io web3r.io slash auth. This is present I'll share the guide as well. We have a very thorough guide on how to set up everything here odd zero and web3r. So once this is done all these so have this example which I've made. Let's see if it's trying. Yes. So once everything is done what you will get is the details like this, the verifier name the network which is which this is on and then basically that and then let's see this particular code. I'll try to just not go deeper into the code because this you can always explore more. So let's say we are using this particular SDK of web3r. Web3r slash no modal. Basically web3r has two of the product where you see where you have seen that like there was a modal which gives you the social provider, email SMS as well as the options to connect with external provider but we also have no modal SDK which is complete UI less one can just customize however they want to use the authentication method. So we're using web3r for modal SDK and out of this what is important is that we are using the client ID. So how do we get that? So I talked about the project. So once you create a project at web3r you will get the client ID from here. Note that this project is on let's say if you're selected Sophia mainnet this is what we are using here in this network web3r network as a web3r no modal constructor. You have to pass the same network which is present on the which you have created on the dashboard basically the Sophia mainnet. So this is the variable which you can use it to just get the same name or you can just use the string as well. So what we are doing is basically initializing the constructor like this needs a client ID which is already here it needs to come from dashboard.web3r.io then this is more of a chain config needed for more of the ethereum, this is more of a ethereum specific. This is how on which chain you want to connect with. In this case this is goerly and if you want to connect with ethereum mainnet just use ox1. Similarly the RPC target and all these details will change so this takes an input as like a chain ID and chain config basically so it takes the chain ID which we have created on the dashboard then the chain config and apart from that this takes the web3r network and feel free to ignore this this is more of a in-depth one but yeah this uses something called corekit which is another product of ours. But from that what is needed for this to work is this particular thing. So in open login adapter we have to have a jwt login config. Here goes your verifier name. That is why this says of everything about like create verifiers and this is going to be your web3r odd0 demo. So this is the verifier name and the login is based on jwt so we have for odd0 and everything any custom one we use type of login as jwt and the client ID is needed so we know like which of the application at the odd0 side is being connected. Then apart from that this is just basic generic code and once you do login here you just need to pass something called a domain under extra login options which is the one which we have used it here and then and the verifier is based on the verifier ID field is based on sub. So let's see in action also there is a cool feature that I'll show you more about this in actions. Let's see how this looks like in action. So we have this code okay I think I've come to the directly to the source code. Yes let's see in action once you click on login it takes you to the odd0 modal. So how do we enable this right and how do we configure this so you have to go back to the odd0 dashboard and under authentication type you have to select whatever social login so I have enabled these these are most of right now is odd0's developer configs like Apple discord so all these you need to configure by creating a connection and then inputting the fields what you want. So I think I'm exhausted in my limits here but in this case like you would have you would do something like this like enable let's say enable facebook, github or whatever I mean all those social options what you get is the client ID and secret I think odd0 once you once you do it for the first time they have a really cool guide here which you can also I think by clicking it here you can see the whole guide like how to set it up and from github and configure it for for odd0 then what you need to do is go to the application what you just created on odd0 side then under connections you just need to enable those so this is really handy for whatever I mean even in production as well so you don't have to you know start like build it again just to use the same options so let's say here it says these I think pretty much whoever uses odd0 they know like once you disable it here and then that's it what is needed for this to to not show up here right so let's see if you do this see it looks like I have not saved it or it does take some time but pretty much this is what you get right for Deepa maybe you can confirm later on but pretty much once you disable that you will not see it here but let's proceed with let's say google so once you do signing up with google then what it does is that it gives us the id token here if you have seen the url and the authentication has been successful so what are the things what odd0 has odd0 has something called a function expose like getUserInfo once you do that since this is just a demo app I haven't done much of the UI I think it's more of a straight forward it gets in the JSON format your name your profile pic and all those details and if you see about the verifier id as we have selected sub which is this but if you don't believe just look at the oauth id token and let's go to iconickdf2t.io I have also already been there let's replace this and try to find this so this is exactly what the sub is and this is based on that this is the application is based on this this particular sub id out of which we have more things like more of the blockchains we also have similar things at web3 also that if you want to do server side verification for odd0 sorry for with web3 odd then you can use authenticate to use a function which is behind the scene I'll show you this also gives you an id token which is of a similar format if you go and paste it here on id you get more of the odd0s sorry web3 os related specific details like the public key associated with your public address what's being generated on ethereum this is the curve what's being selected for ethereum like 56k1 curve so pretty much this and what you get after logging is the this address which is of an ethereum address since this is based on test testnet so I've already I've already added some points here just to demonstrate this is 0.29 something ethos then what it enables use to have the sign message functions so that one can verify the authenticity of your particular account also it gives you more of the flexibilities like how do you transfer your funds so I've just clicked the send transaction hopefully if everything goes you'll get the transaction hash and everything around your transaction data which we can verify on ethos scan of the query basically so this has been done I mean one can just set up the loader screens and everything around that just to look cool and process properly I was just testing previously so but you can see this transaction has still going on this is successful so the funds from this account which is basically the account what we get after doing the authentication with Auth0 and Web3auth this is the ethereum account which is exactly the same and this is the other account which is in the course it's not like it's from anywhere this is very typical address like send transactions how you do the send transactions in Web3 is like you take a reference of Web3 package and then from address destination and how much amount of money you want to transfer and this is how the transaction block function looks like and this has all these details here if you want to click on more details it gives you more of the details of this particular functions so we have successfully made that thing and yes this is another function we have is like get the private key so this is the private key associated with your account and you can export it to other platforms other applications other wallets as well there are some cool features what you can do with interoperability as well with Web3auth so this is how the whole application looks like and I think this course code is available here and if you are joining in you can just go to w3a-a0.virtual.app I have hosted this app on live server so you can still use this and try to get login it will be similar experience basically just login oh yeah it does take some time I have disabled the Apple one so you can see that the Apple is not here anymore if you sign in with Google you will get the exact same thing so the other thing I wanted to share is more about that one thing which was on the comments so if you see Apple TSX so there is one functions like one variable connection if you pass Google OAuth 2 which is exactly what you see here Google OAuth 2 or Facebook or Discord whatever is configured and what's the name here if you just pass this function what happens basically let's see here on the local host what it will does is that it will directly go to Google because we have just said it not to show the modal for users to connect with so if you are doing some just utilizing the login and if you don't want that modal to show up you can do that similarly you can do it with any login basically this is how it is and pretty much this and then the source code is available here feel free to clone it just try out I don't think you would need any specific details here because the client ID is already set up but if you want to use it in your project feel free to sign up for the dashboard I think it's more free to explore and then do the logins this is what it is the live demo is at w3a hyphen this is the live demo and in the demo itself there is the link to the source code and you can find me at basically if you have any queries about authentication odd 0 with 3rd, id2 and jwt feel free to shoot me on telegram or any other places as well I'm available on most of the platforms at mdsbzallem so yeah over to Dyson if you have any queries Deepa thank you that was a very engaging full demo on speech it was very good too much information I'm trying to catch up I'm still learning battery I'm surprised that odd 0 has integration with 3rd that was good hey Dyson, what do you feel about the talk? well I didn't know about web3 as well but it's great to see that you can integrate with the web3 authentication and the author of the authentication we recently released past keys as an EA so it would be nice to have web3 authentication with the biometrics in the future we are also exploring that and I think what odd 0 has done previously is more seamlessly than the onboarding on web2 users through that particular model the iconic odd 0 model with that what web3 odd is trying to do is exactly the same with better experience of logins no one has to worry about sheet phrases also in other factors like past keys, biometrics, face IDs and everything is there with web3 odd as well and I think if it's if web3 odd 0 is exploring definitely there will be a way where one can use it as a first factor as well as in the second factor definitely we have one question from the audience so let me block the can you clarify again where does your app draw the A term from okay yes so if you see it's more of a contract of how it's being laid out in the background what web3 odd gives you is the provider based on that particular account it will go into detail but I would say if you go into the docs of web3 odd we have like how the infrastructure work and I just see it here which will be around like here so there are different node architectures we are using like the one I just described is all about the SSS architecture where the private key retrieval happens on the front end which is more of a TSS based MPC where the private key does not happen but has the same capability for users to get the signed signature so that they can use it on the on the blockchain so I would love you to read more about how web3 odd works it just won't be good for the time on like how this happens on here but feel free to explore that or if you want more we have also have a community platform where you can just ask this particular question and I would love to address that there thanks Shabazz and thanks Amit for the question I don't think we have any more questions but if you have any question please drop the question in the chat I think Shabazz can stay for a little bit longer so he can join us later sure and yeah we can have a chat so I think that's all for now thank you Shabazz we'll see you at the end of this talk so let's bring up the next section wow this is something new which we are trying so we are going to introduce this new session called ask our IT experts we being from an IT company wanted to give an answer if we have any specific questions on IT you know how to implement what to or am I doing the right thing what's the best practice so we are opening this floor so you don't have to necessarily skew your questions only on the talk but anything on questions on IT and security if you are building an application if you want to see like if you have any questions on whether you are doing the right thing or just talk or something if you want to ask we are opening this floor for you so if you have any questions for detailed one we can also leave it at the YouTube comments and how to implement it we'll give our resources and we can get it up from there but if there's something that we can answer right away we are using this floor so what we did is like we talked to developers in different forums like in conferences in meetups and through social media we will introduce this session, this platform to ask questions so today that I'm the expert is going to be Dyson and I have four questions for you which I got it from social media and different platforms so Dyson are you ready I have the questions for you I'm still learning the identity and security things because I recently joined Okta but I'm trying to do as much as I can I'm not going to answer any questions I'm going to ask back the Prageeper to answer the question but I'm ready for that. Alright okay so often it get asked like are we doing the same thing what is authentication and what is authorization the word sounds similar and is it possible like I just want to know the difference between when you say authentication what do you mean by that or is one is a subset of the other I just want to know what is the difference between authentication and authorization if you could explain it yeah it's pretty much confusing it's still confusing me but I'm trying to do my best so the authentication is the act of proving somebody or something who they are they say they are so let's say hey I'm Dyson then I you know if we authenticate Dyson you know make sure that the person is Dyson so usually it's by ID and a password or like SMS messaging or like even with the biometric things so it doesn't really tell what I can do with the system but it can buy who I am so that's the authentication that I believe the authorization is different it doesn't really care who you are but after that you are authenticated you know you make a request hey I want to look at the user data then authorization kicks in hey if Dyson can look at the user data if it is then yes we authorize so usually it's authorization comes after the authentication because without the authentication everyone can ask for the permission hey I want to look at the data but I'm nobody so that's the difference between the authentication and the authorization and probably you can add more context if you want to yeah I like this word I read it in our blog which says that authentication creates a digital identity for you so if I'm user I'm apradipa.p at gmail.com and whenever I log in to any application the application identifies me and as my email address or my biometric so it creates a digital identity for you it doesn't necessarily have to be your you know personal identity so that's what I say authentication like you mentioned like I am just to prove that who I am is what I am it's what authentication is if you want to say hey I want to access photos of Pradipa and then okay who you call you right so that's you can just provide you have an ID information as name Pradipa but it doesn't say that I can access Pradipa's email unless I log in with my gmail with my user ID and password I prove that I have access to those stuff so that's authorization thanks for answering that question and if you go into the world of OAuth 2.0 which is the normal you see in most of the e-commerce applications or anywhere you see like login with Google or login with Facebook and OAuth 2.0 is everywhere but as a developer if I want to see I always get the difference I will always get tokens tokens tokens everywhere and one one question is what is ID token and what is access token and why do we need both yeah what are the ID and access tokens for this is another confusing concept or the mechanism that you know I'm still struggling with the what's the difference is better so the ID token is the artifact that provides the user has been authenticated and it was introduced by the open ID connect so ICD so that's the after the authentication then you get the hey this person is authenticated with the token and also it's signed by the key I mean the public and private key so that makes sure that token is valid on the other hand access token is not from the open ID connect it's there or to you know specification so I believe so it's pretty much different from the ID token and this is the the artifact that allows the client application to access to the user's resource so let's say your application wants to post a comment on the LinkedIn then the application asks I mean the after you authorized the permission then LinkedIn can provide the application to the access token which has the permission kind of things and in this access token you can use a scope hey this access token can post well it can read but it cannot post well it can post and it can read kind of things so you know when you want to use your application to act something on behalf of you you may need to use the access token and not ID token that's what I'm understanding right now thank you so there are two different protocols where ID token is for open ID connect and access token is for OAuth 2.0 yeah it's very confusing I don't know I'm still laughing all right hope we explain something about if you need something you know to know we'll get it yeah there was one question when to use ID token does anyone elaborate more on it yeah I think so the once you authenticate it then your application can obtain the ID token then you can perform the necessary actions or like your application can get the information from the ID token then the beauty of the ID token is whenever you need to make a request for the next time to your system then you don't have to be reauthenticated but you can use the ID token so whenever you want to make sure that the request is authenticated by the use system then you can use the ID token on the other hand access token is not supposed to be the consumer by the client application so you really don't want to see the details so that's the I think the difference between the ID token and the access token okay one more token coming in which is refresh token do you know why and why do we need refresh token and what is the refresh token you are giving me question it's like challenging me and I'm trying to answer here we go that's a cool part of being a host you just have to have questions you don't have to know the answer yeah you're right so the all tokens has like a lifetime so let's say like 6 hours or 6 months or 3 months depending on the system so usually the access token has a short amount of life because you don't want to make the life longer then if something bad happens the bad actor can use that token to perform the bad things for you so usually the access token has a short amount of time let's say like one hour but after one hour if system wants to perform the action if we don't use the refresh token then we need to ask users to authenticate and give them permission authorization kind of things again which is less convenient so whenever you get the access token first the system provides the refresh token then if you use the refresh token after the access token exploration then you can get the new access token and the new refresh token so without you don't have to reauthenticate it again so that's the way the refresh token works and you want to store the refresh token in a secure place don't disclose to anybody else yeah alright so I can I rephrase it saying that the best practice would be not to have a long lived access token like 365 days or something so that if it gets into the wrong hands then people can do whatever so it's better to have a short lived access token and the primary purpose of the refresh token is to reduce friction so if you go into an application and then if an application keeps on popping up for username and password to identify yourself that's so annoying so that's the purpose of the refresh token to silently go to the authorization server and get the token without directly dedicating okay this is my last question I promise you and this is something that gets asked we get tokens we get questions like JWT which Shavas show like get to the JWT.io and then we can see the token information but there are also tokens called OPEC tokens which do you want to explain what is OPEC token and why do we have to use it? okay so the OPEC token is a random unique string of the characters issued by the authorization server and there's no way for the application to decode or look at the data so it's meant to be used by the authorization server so whenever you send back to the OPEC token the authorization server can use that information to make sure that person is accessing the right data so I think it's on the other hand the ID token you can retrieve the data from the token so if you want to I don't know if it's right but if you want to secure the data kind of things then you can use the OPEC token but I'm not certain so you can add more context yeah I think this is more like you don't have to so some tokens like we mentioned like jwt.io we can validate the tokens ourselves with the private and public key which Shabas has just shown us for OPEC tokens there is no specified format it can be a random string the format is defined by the authorization provider so you don't have to go to you don't have to open the token and then see you just send the token for validation and the authorization server will just look at the token and then validate it and then say this is correct or wrong so that's another way of using the tokens all right I think I see one question better I'm not sure the answer but yeah could you add a little more so we got in the chat in the past read abuse expressed by the octa employee casting jwt as the inferior method of the authentication sessions so we may need to look back in the past who said that and why they said that but if you can guide us point to the talk then we can take a look at it I think we can answer today yeah because we need more context on why and what situation this is valid there is a reason why we use jwt token and there is a reason we could have suggested not to use it it all depends on the context so if you could elaborate more on what is the context and why inferior method of authentication is suggested we could help answer questions we can leave it in the chat that's all about the tokens today tokens tokens tokens can we bring Shavas here sure next time you need to answer the questions don't ask me question to me but I'm going to bring back to Shavas welcome back just wonderful hearing more things Dyson about ID token access token everything it was really good I wanted to jump in on few things as well but you pretty much had it covered good to see you feel free to add more that's for the good of the audience at least answering back to the question what's being asked about what could be the off-time employee must have said could be on a different context but it all depends on the use case what you're doing let's say at Wip3 we're just validating the ID token and then comes the right keyword about refresh token by someone should not have the long lived token something around that so pretty much yes that's the context how they want to see in everything but if you are just using ID token just to validate stuff and have more information about that pretty much that's what you need that for at Wip3 I hope this answers the question if you have more you can just ask and I think we reached the end of the session yeah thank you so much for Dyson for supporting and answering questions and next time I'm going to invite someone else I don't want to be I don't want me to be a scapegoat you better be it's fun asking questions you know true that also fun when you have when you know the answer it's pretty much a pretty fun to answer as well but if you don't know then comes the main part there's always next time anyway and then most of the we know OAuth.vo is already there for a long time and people are using the OAuth 2 applications for a long time but one of the things that I face whenever I go for a conference or a meetup is like when do I use the refresh token why I need a refresh token so all these questions are we think it's already covered I mean talked about it in all the places but it gets the tokens are like key to the entire your work so if you have if you just generate an access token the scope of all let's say in the Gmail let's say in Gmail and if that gets compromised someone can delete all your emails and then that's it gone so we should be very uncautious of creating access tokens with the limited scope and make sure it's short lived we cannot always make sure that we cannot always say that it's not compromised at all so better to be safe that's always about IT and security always be cautious there was always bad actors there it could be a Chrome extension it could be a simple plugin or a phishing email link that can seal all your data so be very uncautious of how use your ID token and access token and with the limited access that's why I wanted to pick these questions out of all the questions to start with the basics and then talk all about the tokens and stuff thank you so much Dyson and thank you so much Shabas and thank you all for joining Shabas you have a last word thanks for having me it was really fun to talk more about ID token and JWTs in general what I've always been loving about so yeah thanks for having me look forward to having maybe in an offline setup or a hybrid setup so yeah we'll be pinging you more of more such ideas around that and especially around identity and security so yeah thanks thanks for the invite have a good day, thank you thank you all for joining and then keeping us engaging see you all in the next month and yeah so thanks for joining and see you guys soon for the next month, bye