Authentication best practices in React and GraphQL by Vladimir Novick | React India 2019

[Music] hello hi everyone more MORE hi everyone really excited to be here really like it here in Goa and I've prepared something special for you today with the slides a kind of different format hope you'll like it and today I will talk about vindication best practices in graph QL but not only in group Caillebotte authentication best practices in general so a little bit about myself this is my fancy logo which is basically just copy paste from vs code so don't judge i'm developer advocate at basura I'm also go Google developer expert author consultant and I do web mobile we are a RIT AI recently and probably if I add blockchain in the future there will be like top of buzzwords right so I like to say I build cyberpunk future in a good way and I want to start this talk with with the sort of a journey to space to talk about authentication so we're here in the spaceship and let's talk about different ways we can authenticate we can use username and password but would you leap out of your spaceship into the void without thinking of your security probably won't right would you use session tokens well you might use session token so actually it's a really good idea for authentication but we are working with distributed systems right we're using micro services we want to scale everything and not necessarily we can keep one centralized token database so we see more and more companies go into JWT solution and today I want to explain all the intricacies of JWT what it is how it's used and let's be honest around 80% of companies out there I use it wrong and we'll see why so let's go into our journey into the new dimension of JW authentication and obviously I need to log in and I will log in and teleport to the new dimension so we'll talk about what JWT is and how it is used we will talk about login logout and we'll talk about a concept called refresh tokens so let's jump in and talk what is JW t so JW t is a token which is used for the purposes of auth and it has some kind of JSON payload that is not encrypted and this is misconception lots of people think JWT is talking I encrypted no they are not they are you can decorate it on the client they are just base64 and the token can be used when talk talking to API now the secure part of JWT token is the token is verified by the backend and it's it's valid it's valid until it's expired so can client impersonate the user well probably yes but validator verification on the backend kind of prevents that but what is what happens if jadibooti is stolen can it be used forever well if you implement you back in incorrectly and you don't have expiry for JWT yes it will be available all the time because you don't store you generate it on the back end but you don't store it in centralized talking supposing all the accession tokens examples so if you go to JW dot ru you will see something like this so on the left side you can see a token and lots of people think it's encrypted again it's not on the right side you will see the how token is decoded and as you can see it consists of three parts the first part is a header that defines the algorithm that will be used for encoding or decoding the second part is a payload which consists of data that you want to pass so don't pass sensitive data in your JW payload and the third one is the signature that is there are different algorithms there are different types of single signatures there are some that use just a secret key world some that is private key there are different algorithms you can browse through jadibooti that io and read more about that now the diagram of what's going on it looks like that and let me walk you through this so we have our app right and we send a login request on the server token is service a serialized to the base64 encode header and payload and you sign using the algorithm and the payload claim now what happens the the micro service like the whole business logic and everything here the verification happens here you get the claims that they to do business logic verify and go back to or not so that's that's how it can be done but let's look further at login and we have the different dimension here of login logout let's jump inside oh so how does it look like let's strip it down to smaller parts and look at the granular so login request generates a devotee token - getting back - enough what lots of companies doing wrong where do you store JWT if you google the answer you will see local storage and it's wrong because local storage is accessible XSS attacks can just take your jelly booty from the local storage use it in person it user and yeah it sure with verification is harder but it's possible to get the total so he stole token and memory don't store it in cookies you don't you can say ok I will store it in HTTP only cookie but then there is cross-site request forgery which you can also look further into it so there are different security considerations when storing JW so the only way to store it secure is to store it in memory so in a nutshell you the sub login will look like that you will have the username and password and in response you will get this jadibooti token right now I already told you never store it in cookies local storage you store it in memory just like that well little bit more complicated than that but you store ball JWT and you store the expiry now what happens if there is no token you read your actual game so as simple as that now what happens in the app itself when you do post request to your gruff tail end point you check of his token is in memory and if it's no well we already seen that your there are two open string if it's there you simply pass it in handle so far everything is good right everything is fast to my graphical client I define my Apollo client passing the authorization bearer token that I got so far everything is good everything is working what about errors what if I have Network error and like jadibooti is invalid it has its expiry date they tried so we just use on error from a polluting error and it just works now what about log out log in out is a little bit more complicated and to be honest to log out like a simple log out is just deleting your JW from memory because we dealt dealt with errors right what will happen will be requests to graph QL server token is X part is not there will redirect you again but there is another request secure the log out request and you see the blacklisted token list and verification and verified not lettuces so what is that typically you have 15 minutes that's the best practice 15 minutes of expiry for your data about it ok but sometimes in really like secure ops you want to keep it even when you log when you log out you want you delete this token completely now token is not stored anywhere so the only possible way to blacklist this token is to keep it in some kind of database for these 15 minutes or the rest till its expiry date now you can argue on that and saying that you just said Jade ability doesn't need centralized token database yeah let's try it it doesn't need blacklisting does need something like that so it's a trade-off so think something like that if you log out your token will be still valid for the difference between the logout and the end of expiry date so if you want to limit that yeah do black listing it and do play black this database something that now we have and you probably already spotted several problems with that we start talking in memory right so there are several questions that trace first user will be logged out every 15 minutes right we don't want that we want user to stay in our app so what happens if we're in banking systems there we usually show user you able to log out please like do you want to continue to say sometimes some systems doesn't need that so so they use different method that we will talk about but there is another problem more dominant one what if I open another tab just simple things like open in another tab basically will mean I'm starting my up without talking in memory so what will happen in our app redirect you again do I want to log in every single time in different tab no I don't right so how would you do we solve this and we solve this with something that is called refresh token now we can say oh come on session tokens JWT now refresh tokens like how do I supposed to know all of this stuff and I have more diagrams for you so no worries now this diagram in this diagram that that's what's going on the login request execute login request log an endpoint and generates a double token and refresh token now a refresh token is stalled in database and refresh token has expired date of something like a month now refresh token is returned back to the client but it's not returned to the client via response its return to the client using set cookie and we'll see later on as HTTP only now jadibooti is stored in memory as you can see here and we start calm down we start count count down to something that is called silent refresh so whenever use 15 minutes pass we check our JWT if it's about to expire where is it get another request to get to know different endpoint to get us to get refresh token and this refresh token will get us jadibooti bet so how does it look like we call refresh token refresh token is passed in the cookie now when I use that HTTP only cookie this cookie is not accessible or in JavaScript on the browser so cookies send that from the server to the client it's secure for cross-site scripting attacks but it sends back to the Refresh token endpoint whenever you want to refresh your JWT and refresh token does exactly that it verifies refresh token in the database and it generates you the ability now what can happen you will have to differentiate abilities in two different tabs is this fine yeah actually it is because they have different expiry they have different count down so that's perfectly fine and setting cookie work across all browsers thoughts so our refresh token is refreshed again as well now the important part about refresh token when it's told when you store it in the database and when you do this verification you actually delete the old one so you regenerate both the JWT and refresh token so it means even if which is almost not possible but even if your refresh token is stolen somehow then it will be valid for only one for getting only one JWT but getting only one JWT through sending requests from the same single domain because from different domain HTTP only cookie will simply won't pass to the server so it's safe from exercise it's safe from cross CSRF and it is good so how do we persist sessions have a new session in the table we try some to refresh you with if we fail we do redirect so again if we succeed we basically start our account down on a different tab and I want to show you the code I can rush through my slides before showing the cold I want to thank you for being in the space and we'll jump from the space into our vs code editor and hope it won't break the immersion so let's see what we will do when we have server-side rendering services rendering we can have different problems additional problems actually we render our page right we get let's say we re render our page we logged in everything is good talking in memory I render my page what happens when page is rendered on the on the server what happens is refresh refresh token end point will get in you JWT it will be stored in memory on the server right and then everything will be rendered to the client what would the like working and with the getting all the data from the Roth : pointer no but your refresh token will be wrong so another click on the same tab will basically log you out and this is sometimes frustrating within apps such as like in general necessary so let's look through the code and let's see what's actually happening here and it's just like a really simple example so we have our app we have our index we we are in next GSL actually right how many of you familiar with next yes good so the ones that no no no mirror is a really good solution for server-side rendering apps you should check this out the idea is everything under pages is different routes and I have here an index route and the logging road right so if I look in my login route I will have I will have the login right so I want you fetch can you see the phone yeah okay Chris a little bit so we have the handle submit and we have the the fetch so we get the username we get the jadibooti talking J that what you talking expiry as I told you if there are errors withdraw errors and we set user data right and we really gain some we move to different route to our up get now our objects uses without off seeing higher order component that it comes from utils with all thing is the component that does all the logic and let's see what what is doing with all things let me find it okay hear this so basically in this year's get initial probes will be executed on the server to get my initial probes with contacts and I called the auth function passing in the context to basically get authenticated now if I don't have a memory token then I set the token if I have it everything is fine now all the magic happens in earth so what what do I have here I get refresh token from cookie now you can say wait a second you said refresh token was HTTP only right so how I supposed to get it from from the cookie so here I'm on the server so I'm able to get the cookie as soon as I am on the same domain as soon as my API login endpoint on the same domain so I get the Refresh token if I don't have memory token so basically what I do I get a cookie and get the URL right and I fetch to my refresh token right so this is like silent refresh that is happening now it happens both on the client and on the server and I told you the problem in SSR that you do like twice you do refresh token twice you do it on the server and do it on the client so you need to update this refresh token when you render things on the client so here I am getting my refresh token and this is what solves SSR so you said you you check if you're on the server you set your refresh token till the updated one now this is a small trick that will fix all the like SSR thing because we will have the same token passing through now we'll still have two requests execute with one from the server one from the client but at least we will fix that we won't have redirect to login now obviously there are lots of like trade-offs and lots of things that may be not that clear from from from the top and or you need to I did more interest so I try in this talk to show you different ways and actually the suggested way to use the abilities and the most secure way to use chat about it is now I will after the talk I will tweet the blog post that I wrote that explains further with more details getting more into code because of time constraints I don't have time to explain everything so you'll have time to read this on your own what I want to focus on though what I that when you get another ticket so you get another login working think twice think twice what about security what about all the edge cases like reloading SSR like what about different tabs think about this twice and think how you can create your apps in the most secure way possible because unfortunately security is the last thing in mind in lots of companies and lots of businesses and I think it's fundamentally wrong because you just expose your business to hugger attacks and you don't want that so I was pretty fast trying through the size of the code so that's all that I have for today thank you so much for being here for listening if you have questions I'm open to to answer and presentation will be available online so you can play around walk through the its WebGL with webassembly it's available just to walk through play around row don't go to poles you fall into space I told you it's not secure and follow me on twitter at valanor Novik i will have more stuff in upcoming days unreasonable on graph kill and all of these technologies I work with thanks so much this video recording was brought to you by Twilio we allow you to integrate different means of communication such as video chat or SMS into your react applications if you want to learn how you can send SMS directly from a react chat check out this video on the right or go to our Twilio youtube channel and if you want to watch another react india talk we picked one out just for you over here on the left thanks for watching

Channel: Geekabyte

Views: 693

Rating: 5 out of 5

Keywords: goa, India, conference, tech, javascript, 2019, india, React, reactjs, react, coding, 2020

Id: ym80EkHnArs

Length: 24min 48sec (1488 seconds)

Published: Mon Nov 18 2019