Cookies, Sessions, JSON Web Tokens (JWT) and More 🍪🔐

hey welcome back to this bootcamp series in this video we're going to learn about cookies sessions and json web tokens if you have no idea what any of those things are that's okay that's sort of the whole point of this video we'll jump into the technical aspects in just a minute but for now sort of the big picture theme of this video is how we can have a server sort of remember or trust a visitor also real quick before we get started i just want to say that this entire bootcamp series is sponsored by me so i have several premium video courses on web development available on udemy and in the description for this video you'll find links to join them at the best possible prices anyways without further ado let's jump into the action and let's begin with cookies okay now if you've been following along with this entire bootcamp series you're at least a little bit familiar with node and express so there's nothing too interesting going on here i'm just setting up a basic server i've got my home page route and i'm listening on port 3000 so if i visit localhost colon3000 we see hello world now let's imagine i want my server to tell the visiting web browser to store a little piece of data in a cookie well within this home page route before we send back our final response you can just say response dot and there's a method of cookie so we give it two arguments basically a key value pair so we can make up a name for the cookie let's say sky and it should have a value of blue right then you could set another cookie response cookie say grass should have a value of green now if i save this and restart my server now if i refresh those two cookies are now stored in my browser if you want to see them you can just open up your dev tools so you can right click choose inspect instead of the elements tab click on the application tab or if you're using firefox instead of chrome there's a tab called storage anyways on the left hand side then we're looking for cookies and you do need to click on your specific domain that you're currently working with cool and there we see our two cookies now let me show you why cookies are interesting or useful so if we go back to our server and we get rid of these lines that set or create the cookie on the browser right and i save that and restart my server now even if i refresh those cookies are still there right they are stored persistently in the browser no matter how many times i reload and what really makes cookies useful is that the web browser by default will send along any and all cookies for the current domain in question back to the server on each and every request so as i'm sitting here refreshing over and over again each time i refresh the browser is sending this data back to the server let me prove that to you so we can actually see this cookie data from the browser getting sent back to the server so back in express we previously had this code now yes you can set cookies in express without any extra packages but if you want to be able to easily read incoming cookies being sent from the browser you do want to install a package so i'm going to stop my server and i'm going to use npm to install a package called cookie dash parser okay so just npm install cookie parser let's go ahead and import that or require it in so const cookie parser equals require cookie parser okay then i'm just going to use that piece of middleware so just i'll use it globally so i'll just say app.use cookie parser parentheses to actually call it okay now check this out for this homepage route let's log to the console any cookies that the browser is sending to us so we can just say just as a quick test console.log request.cookies so that's what this middleware is doing it's making the cookies easily readable from request.cookies so i save that and restart my server and then every time i reload the browser back in the server's console you'll see sky blue grass green and just to really prove that this is coming from the browser you could go back into your cookies with your dev tools and i could set sky to have a value of gray push enter and now when i refresh back in the server's console you see that value here sky gray so this is why cookies are so useful you can set them once and then the browser just automatically sends them along with each and every request and it doesn't matter if it's a get request post request any type of request you're going to get those cookies sent to you on your server side now a little bit later in the video we'll see a few examples of interesting ways that you could use incoming cookie values but before we get to that i do want to show you that you can also access cookies from front end or client-side javascript so it's not just the server side so for example if you go into your browser's console to simulate a bit of client-side javascript coming from the server you can just say document.cookie and that's going to give you any and all cookies for this domain at least now in certain situations it's okay to allow client-side javascript to access cookies like this if you're not storing anything private or security related this is okay so for example maybe just a color scheme preference or a ui layout preference that would be fine however if you're storing anything even remotely private in a cookie i think it's a good idea to disable client-side javascript access like this so right now let me show you how you can do that back on the server side let me comment out this console.log line and instead let's set those cookies again from the server side so we can just say response dot cookie let's just set the same values again so a name of sky with a value of blue only we can give it a third argument a configuration object and if we give it a property of http only and set that to true well let's go ahead and save that and see what it does so if i restart my server and go back and refresh now when i run document.cookie to try and access it from client-side javascript i can only access the green the grass cookie so if we go back to application and look at all of our cookies you can see that for the sky equals blue cookie it has a check mark next to this http only property so when a cookie is http only the browser will still send it along with each request to the server but it makes the cookie not accessible from client-side javascript which in my opinion in the opinion of many others this makes things a little bit more secure right because now if you have a bit of malicious gone rogue client-side javascript that somehow made its way into your site's code base it at least can't access any private cookie data we'll talk a little bit more about that topic later in the video but for now let me show you a few other cookie options so you could also say comma give it a property or option of secure and if you set that to true i'm not actually going to do this but this would make things so that the cookie will only be used on https domains since locally i'm running on http just for quick development testing reasons it would essentially make the cookie not be used now in the real world once you've deployed your app actually up onto the web this is a very important option to make sure you're using another useful option would be max age this lets us say when the cookie should expire now it's measured in milliseconds so let's do a quick experiment if i set this to 12 000 milliseconds that's 12 seconds so let me save that and then restart my server so back in the browser now let me remove this so the cookie's not being sent and let me see if i can do this fast enough to show you the test now if i refresh that cookie is still there but in 12 seconds from now keep refreshing you can see yes the sky equals blue it expired so the browser knows to automatically delete it okay so those milliseconds are measured from when the cookie is created after that much time passes the browser will know to remove the cookie now there are other cookie options but i'm not going to bother going through each and every one of them if you're interested you can go to the express documentation cookies don't have anything to do with express in particular right so you could go to the official php documentation or whichever server side language or library or framework you're using and find these basically these same options okay at this point though let's change gears only before we learn how to do anything actually meaningful with cookies i first need to show you the biggest security exploit related to cookies because before you even think about using cookie data for something important with real world consequences you need to be aware of this vulnerability so it's something called cross site request forgery or csrf for short and i want to show you both how it works and how to protect ourselves against it so for this next example you can actually visit my github i've created this repo called youtube cookies and more and for this next example that we're going to walk through i'm using code from this 01 cookies folder okay so off camera i'm going to pull up those files right now okay now i will point out that in that code from github that i just showed you it already has csrf protection implemented but in this quick example on the screen right now on my computer i've removed the csrf protection so i can show you how this type of attack can successfully go through and then also how to implement the protection sort of line by line okay so what we're looking at here is a very simple server setup you've got your home page route and it's setting a cookie named simple test or the value of cordy so you could imagine that this was some sort of sensitive value and then the home page has a html form let's actually just spin up the server so you can see what's going on okay so if i visit localhost 3000 there's just this form right we could use our imagination and pretend this is for a bank website where you set an amount and then who you want to send it to now before i hit submit let me show you what's going on so it's giving me a cookie if we look at our dev tools so this example created a cookie named simple test right and then it gave it that value of cordy and again imagine this was some sort of secret or private value that the server is then going to look for because if we look at what happens when you submit the html form it's going to send a post request to transfer money and if we look at that route it's going to run an if else and saying only if the incoming cookie named simple test equals corty right then let the request go through otherwise have it fail so if i test this out and try to send this request we see success now you could use your imagination and imagine that the server would only give me this cookie if i passed some sort of test right like if i logged in with correct credentials or something along those lines so now even if you commented that line out that creates the cookie restart the server that cookie still exists in my browser right so if i try another request it works this is great however we need to remember that there are malicious people in the world um so now let me show you how a csrf attack could happen now actually google chrome recently made a few changes that will block some of these types of attacks so that's great so i'm actually going to use firefox just to show you how one of these attacks could go through so let me put that line back that actually sets the cookie restart the server now let me try this in firefox where a csrf attack can still easily take place so if i refresh in firefox yes i have the cookie so if i try to send an amount it works however if i as the user now visit a different website in a different tab right so i'm using codepen and you can see this is bad guy site pretending to be good guy site and you can see there's this button down here that says click if you like puppies now who wouldn't click that button right we all like puppies however before i click it notice that it's part of a form if we look at the code with hidden inputs and the form has an action that's going to try to post to my transfer money url now this bad guy domain that i'm visiting it can't access the cookie from a different domain right so our cookie value is safe and secure the vulnerability comes into play because this is going to send a request to this url that we own on our behalf in other words the bad guy site doesn't even need to know the value of our secret cookie in order to take advantage of us right so the bad guy site is going to send a request to our domain and then you can see there's hidden inputs where they're going to send 99 million billion dollars to bad guy so if i click this button success uh oh it went through so this is a security nightmare the reason this type of attack works is it's taking advantage of the very nature of cookies right cookies are automatically sent along to each and every request made to that domain so in order to stop this type of attack from working we need to think about what badguysite.com can and can't access so really it can't access anything on our actual website right it can't access the html the css so the easiest way around this if we go back to this screen is to just have some sort of value in the actual html or dom right because badguysite.com will not be able to access that they're just taking advantage of the fact that cookies get sent along automatically so we can have a value in our html and then only if that value is a match or makes sense only then do we let the request go through now to implement something like that in express there's a great package called sea surf so right now off camera let me pull up this code from the o1 cookies folder uh because this shows you how to implement sea surf protection okay so here's the code with the protection implemented so i'm using a package from npm called sea and then this is just boilerplate configuration for the package you could find that on the packages documentation page but essentially this is now a piece of middleware that i can use for either specific routes or i could use it globally for all of my routes but what it does is if you use it on a get request right a page where maybe you'd have a html form what it does is it makes a token available to you so you can see in this html form that the user can submit i have a hidden field with a specific name of underscore csrf and it has a value and then this is what the middleware is making possible it's going to generate a token value okay and now when you submit this form right the transfer money post request i'm using that as a piece of middleware and the package will check for this token value with this underscore csrf name and if it doesn't like the value or if the value is blank it's going to throw an error right so this will just not go through at all instead we're catching the error down here we're saying if the error equals ebad csrf token so yeah let's take it for a test drive so if i restart my server back in firefox if i refresh and try this so it still goes through however back in codepen if i try the attack again let me just add a little bit of code to refresh the code pen view click here if you like puppies csrf attack detected cool so it fails because there's no way for badguy.com to actually access the dom or the html value that hidden input with the csrf token so that's just a quick example of how you can use cookies without being open to that really popular csrf attack at this point let's change gears because now i want to show you the most common way that cookies are actually used in a meaningful way in the real world and this is something called sessions so back on my github repo you can see this o2 folder o2 sessions this is the code that i'm going to be walking through next so off camera let me pull that up okay and before we walk through this code let's actually just see what it's doing so let me start up the server and if we go refresh localhost okay so we see it's greeting us but it's considering our name to be guest however if we fill out this form and say that our name is brad submit says thank you you can go back home and now it remembers my name and no matter how many times i refresh it remembers my name now this is in google chrome but if i jump to a totally different browser with different cookies so here's firefox um i can do the same thing right so i can say my name is barks a lot submit click to go back home and it remembers me now you might be thinking well what's the difference we just learned about cookies so aren't you just storing the name in a cookie no that's not what's going on so if you actually look at the cookies for this current domain you can delete the simple test cookie that's from the previous example but you'll notice there's a cookie named connect.sid sid stands for session id and the value here's what's important if you look at the value it's a really long value so i had to copy and paste it so you could see how long it is but this is a session id what in the world does that mean well what's going on is our browser in the cookie value it's not storing the value of barcelot or back in chrome of my name instead the server is storing that actual value in memory or in a database we'll talk about that in just a bit but the server is responsible for storing the session data this session id as a cookie right that's going to get sent along from the browser to the server on each request and really that's just letting the server know which individual unique session that you are right so it's sort of creating this persistent ongoing back and forth between the browser and server that otherwise wouldn't exist with just the http protocol in general in other words it's letting the server keep track that i'm the same person that i was just a moment ago when i input my name you might be wondering well what's the point of this why would you bother keeping that data or that value on the server side why wouldn't you just keep it in a cookie on the client side well it's because now we can trust these values right if we're the ones actually storing them on the server side we have control over them we can validate them we can sanitize them we can use these values in our application right because we can't actually trust the value in a cookie because you saw how easy it is for a user to go in here and manipulate their cookie right so if i change my connect id and then refresh the server doesn't recognize me right now i'm back to guest that's why we want the data that we would actually use to live on the server side right because instead if we were storing it on the client side someone could just create a cookie named bank balance and then set their value to 99 trillion so if i refresh again and fill out my name submit it's going to give me a new cookie if i go back home and refresh you might need to click off of that cookie screen in your dev tools and then click back onto it to see the latest data but now you can see again my connect.sid has a new value cool let's take a look at the actual code of how this is working on our server side so you can see i'm using this package from npm called express session and i'm using it as a piece of middleware here globally for all of my routes we're just giving it a configuration object nothing too interesting going on here this is just a boilerplate that you can read about in the express session documentation but now with this middleware in place let me show you the part that's actually interesting so if we go down to our homepage route i'm saying first of all i'm creating a variable of name and setting it to guest but then i'm saying if there is session data for the current visitor then set that variable to whatever the session value is otherwise just let it remain guest okay now if someone does fill out that form and submit the form then that's going to run our post route for choose name so down here post request for choose name this is the interesting part so this thanks to that middleware of express session this is how you can store data for this unique session right it adds a session object onto our request object and then this is just me pulling in the value of whatever the user typed in now i do want to point out there's nothing special about this word of user i made that up so you can set any sort of data you want so you have this request dot session object and now you're free to store whatever you want to store on it so we could say request dot session dot fave color equals purple or instead of hard coding this value you could imagine you pulled that from a form field or from your database or anything right the possibilities are endless so you can just say request dot session dot whatever so i just want to make that clear so you don't think that you need to always use dot user that was just an example really you just have this object and you're free to store whatever you want to store in it okay and then back up in the form that we looked at just a moment ago that's where we're pulling that stored name from from request.session okay and then if someone clicks the log out button that's just going to send a post request to slash logout we have a route down here that's just going to call session has a method called destroy that's all that's going on now this is all well and good but if sessions are still confusing and it's not making sense to you in terms of how the server is really holding on to this data that's okay in just a minute we're going to look at another example of sessions where you can actually visualize and see the data that the server is storing i think being able to see the session id in a mongodb database will make it crystal clear what's going on and how this actually works so i do want to point out that this default way that we're using sessions in this code example this is only designed for testing and local development you would never use express session like this on a real server and i'll show you why because if i stop this server so control c and then start it up again it loses track as soon as i refresh notice it doesn't remember me it lost all of that session data that it was storing in memory so in the real world when you're not just running locally and developing you would want your session data to have some sort of persistence so in case your server crashes and you need to reboot you don't lose all of that session data so the next example that we're going to talk about and i think this next example will also make sessions a lot clearer is this 03 sessions with db folder by the end of this example i think sessions will be crystal clear for you so off camera let me open up this code okay now this code is exactly the same with one exception so now instead of storing the session data in memory we're storing the session data in a mongodb database now you don't need to follow along but if you do want to follow along you can just run npm install in this folder and then you do also need to create a file named dot env and have a variable named uppercaseconnectionstring and then set that to a working mongodb connection string if that doesn't make any sense that's okay but in our previous video on this channel we learned all about mongodb in connection strings anyways let's take this for a test drive so let me start up the server everything is exactly the same other than the fact that our session data is now using a store that's a database let me show you why this is cool so let's start up the server do be aware that instead of index or app we do want to call db.js that's the file the db.js file is what we actually want to start to begin the server okay so now back in chrome if i visit localhost 3000 i can set my name to persloud go back home cool only now our nodejs server is not storing that data of pers loud instead our database is so here i am in mongodb you can see i have a database called youtube session connect and it has one collection named sessions so i didn't have to name this collection the npm packages were using of connect and express session they came up with that name but if i look inside that collection it has one document or one item for that session i just created where i said my name was persloud so you can see it has an id and now yours will be different because this is randomly generated but it's v v-u-r-w-i-v and this corresponds with the session id that my cookie is holding on to so if you go into your dev tools my cookie for connect dot sid if we look at its value now this beginning s percentage 3a that's always going to be there but then directly following that you can see that this matches the session id in the database so essentially what's going on is our cookies being sent on every request from the browser to the server the server receives this and it says hey that's a match right that is a valid session id that i have in my session store so i can trust that you are who you just said you were right if someone doesn't have this exact value in their cookie if it's off by even one character then the server won't trust you but if it is a match it's going to look you up in the session store and then it can use this session data now it's sort of hard to scroll through this and see all of the text so let me copy this into a text file so we can easily read it but you can see towards the end here we have user should have a value of pers loud in other words this data is being stored on the server side or in our database hopefully this is starting to make sense right the browser just sends along a cookie session id if it's a match then we can use this data we can trust this data on the server side so just as another quick example if we tried in firefox right if i say my name is dog submit go back home yes it remembers my name but more importantly if i click find to show all the new entries in the database for this collection now there are two and i won't bore you but obviously my session id and the cookie in firefox is a match for this id and if we look at this data that it's storing right let me paste this in now you can see the user set to dog okay so this concludes our section on sessions now i want to switch gears and talk about something completely different something that is radically different from sessions and it's called json web tokens this could probably be another topic for another video but i really want this video to give you a good idea of how authentication and trusting requests works and json web tokens is an incredibly popular technology so i wanted to include it here so in this same github repo you'll see that folder number o4 is jwt json web token slash local storage what in the world does any of that mean well let's find out right now so off camera let me open up this code okay so here's the code and right away i want to let you know that this is a 180 degrees different from sessions so this is an entirely new topic however it's still sort of solving that same problem of how can we trust requests and how can we sort of remember that someone is who they were just 10 seconds ago right just basically identifying and trusting requests now before we actually dig through this code and really talk about what's going on let's just take it for a test drive only instead of using our browser i'm actually going to use postman because this approach of json web tokens this doesn't even need a web browser to work this is very platform agnostic so let me go ahead and start up the server just node index now i will let you know that we basically just have two routes so you can make a post request to slash login and you can imagine that you actually hook this up to a database with user names and hashed password values but for now i've just hard coded it to if you have a username of john doe and a password of cordy it considers that a successful login okay for now that's really all we need to know about the login route and then after that if you successfully log in you should be able to visit or make a post request to slash top secret and then only if you're logged in should you see this secret message of hello and then it says your name and tells you your favorite color otherwise if you visit slash top secret it should just say failure so let's try out this login route so in postman make a new request set it to a post request to just http localhost 3000 slash login okay let's send over a little bit of json with a username and password so i'm going to click on headers set content type to have a value of application slash json and then we can go into the body tab click raw and just give it a json object right so curly brackets say quotes username should be john doe comma password should be corti well actually first of all let me get this wrong on purpose so if i send that you can see it responds back with but if i get it right just password of cordy says status success but more importantly it gives me a token now let me zoom out a little bit so you can see the token is quite long but now i can use this token for any future request where i want the server to be able to trust me let me show you how this works so go ahead and copy that into your clipboard if you're following along okay and now let's try to send a post request to this top secret url so let's just change the url from slash login to slash top secret okay let's actually get it wrong on purpose so in this raw data if i just empty that out and don't send along any sort of a payload and click send we see failure however let me zoom back in so you can actually read this if i include curly brackets for a json object and say that it should have a property of token and i give that a value quotes and then just paste in my clipboard right that really long token value click send we see status success and it says message hello john doe your favorite color is green and we can tell you the secret info that the sky is blue however if i got this token wrong by even one character right like if i change this last letter from a k to a z click send it says status failure right so you have to have that exact cryptographically secure token in order for it to trust you at this point though let me put that back let me explain how this is working so let's look at the code actually first i want to make it clear that when you're using json web tokens the server is not storing any data whatsoever the data and values themselves are actually included in that really long token value so this means the server doesn't need to store that data in memory it doesn't need to store it in a database the client side is actually indirectly storing those values in the token now you might think isn't that incredibly insecure to ever trust client-side data like that and the answer is well normally it is but with json web tokens this is supposed to be at least cryptographically secure so let's take a look in terms of our login route if you correctly log in with john doe and a password of cordy look what we're giving back we're saying status success but then we're also saying token should be and then we're using the really popular json web token package from npm to sign or generate that really long token value so there's this method of sign you give it an object of what you want to actually live in that token you could have another property in here of fave food and it could have a value of pizza but the idea is when you use the sign method you just give it an object you can store whatever you want to store okay then you also give it a second argument which is your jwt secret now you would want to set this to something very secure you can see i've set it to this string of text you just want to choose something that's difficult or almost impossible to guess okay but all together that's going to generate that token value and then it's up to the client side code to sort of store or hold on to that token value and then when someone visits our top secret route let's take a look at what's going on so you can see we're using a json web token method called verify so in that case we're just giving it the token value that a user is passing along we don't know if this is valid or not if it's a correct token or not however we can give it a callback function and then it will throw an error if that is not a real valid token if it is a real token it's also going to give us the decoded object that was stored in the token so then we can access that right so i'm saying if else for if there's an error if there's not an error well then decoded is going to be that object that we stored in the token so that's how we're able to say hello and then it pulls in the name that we set up here and it says your favorite color is whatever we set up here cool now like i said before this json web token approach can be very platform agnostic so we already saw it in action in postman and really any platform like a native ios or android app they can all make http requests right and they're all capable of storing on or saving a value like this token so you can use your imagination that this json web token approach can be useful in so many different scenarios however this is not a boot camp series on just computer programming in general really this is about web development so now i want to show you how you would use this token approach like this for a website or web application so getting back to our code you'll notice there is a public folder and it has a file called frontend.js so right now let's see this in action so if you still have this server up and running in your command line you can just visit localhost 3000 in your browser okay and then that front-end or client-side javascript file we just looked at that's powering this user interface right so if we get this login wrong on purpose we see sorry try again however if i get it correct well i didn't actually program in a success message so it doesn't actually do anything but now i can click this get secret info button and you see that exact same message from that slash top secret endpoint so essentially when i successfully logged in the browser stored that token in the browser's local storage local storage is really an alternative to cookies it's another way that the browser can persistently store a piece of data and then when i clicked get secret info it sent that token along with the request really quick let me show you where you can see your local storage in a browser so in your dev tools again in chrome it's under application in firefox it'll be under storage but instead of cookies you can just click on local storage for your domain in question and you can just see i've created a key named our token and the value is the actual token itself so then if we look at the client side javascript when we try to fetch that top secret info i'm just using axios to make a request post request and i'm giving it a property of token and i'm pulling that value from local storage so local storage in front-end javascript is simple to use it really just has a few methods you need to remember there's git item to retrieve and then up here i used local storage dot set item that's it so big picture this is an example of how you would use client-side javascript in a web browser to take advantage of json web tokens the reason this approach is neat is it's still very platform agnostic you could have other platforms like ios windows mac android they could all take advantage of these same endpoints on our server side so that's the plus side of using local storage now let's talk about the downside of using local storage now i should have mentioned this a moment ago but the key difference between cookies and local storage is that cookies are sent automatically from the browser to the server on every request local storage does not do that local storage on its own doesn't do anything automatically it really just sits there and it's up to you with your client-side javascript to make something happen what does this mean well remember for security reasons before we were able to say that a cookie should be http only meaning client-side javascript cannot access the cookie whereas with local storage that's not an option the whole point of local storage is that javascript can access it really that's all it can do that's the whole reason it exists the browser is never going to auto magically do anything with your local storage so let me circle back to the actual topic at hand of why perhaps using json web tokens with local storage like this is a bad idea let's talk about worst case scenarios from a security perspective so what i'm getting at is imagine somehow some way malicious client-side javascript made its way into your web app this could happen in several different ways perhaps you're running a social media website and you forget to sanitize user input in a malicious user stores javascript in a field and then when someone else visits your page it runs the javascript or even if you're perfectly sanitizing and escaping all values what if for example google analytics or some other third-party package you're using in your client-side javascript what if that was compromised right and it wasn't really your fault but it was compromised nonetheless well let's look at that worst case scenario and compare local storage to cookies let's start with local storage so if there was malicious client-side javascript running on my site all it would have to do is just say localstorage.getitem our token that's it the bad guys now have our token and they can use this on any computer or device in the world to mimic us to make requests on our behalf they can do absolutely anything they want with this token until this token expires now if you contrast this with if we were using cookies an http only cookie well yes someone could write whatever javascript they want to make requests on our behalf using our cookie and those requests would go through however it's relying upon the innocent person having this tab open as soon as the innocent person closes that browser tab the bad guys can no longer make requests on your behalf right whereas in the previous example once they have your token they can use that token on any device they want for as long as it is not expired so in both of those situations it's horrible right that's a worst possible case scenario that somehow malicious javascript was running on your front end how likely that is to happen is not for me to say but i just wanted to bring that up to you because as you go around on the internet you're going to hear different arguments for and against these different ways of using json web tokens and it's really not for me to say dogmatically you know which approach you should take i'm just trying to make you aware of the pros and cons of all the different approaches so having said that for the final example in this video back in the same github repo you'll notice there's this folder called 05 jwt cookies now i'm not even going to walk through the code on this folder with you i'm including it here though because i encourage you to do a little bit of extra credit and try it yourself essentially i just included this example because i don't want you to associate cookies with sessions and jwt with local storage you could definitely mix and match and that's exactly what i'm doing in this example i'm using http only cookies to store the json web token and it works just fine however what is the trade-off with this approach well my end points are now not super platform agnostic right since i'm relying on cookies they really only work for a web browser so it would not work with necessarily an ios or android native app big picture and this is just my own subjective opinion so take it with a grain of salt i would use this approach well maybe not even necessarily local storage i just mean jwt i would use this for an api right endpoints that you want to be very platform agnostic and i maybe wouldn't even use the json web tokens from my web browser app i would only use them for my api and then for the actual user interface web browser experience i would use this approach with sessions sessions make it easier to handle the edge case scenarios where you need to maybe temporarily ban someone for 20 minutes or for example maybe when they log out you want to give your user an option to log out of all other logged in devices now there are ways that you can get creative and implement those sorts of things with json web tokens but it's not as easy to do as it is with sessions that's just me i'm gonna leave it there because you could ramble about this topic for hours if you search google or stack overflow on this topic you're going to see all sorts of different opinions and best practices it can be overwhelming and confusing as i'm sure parts of this video were that way as well however hopefully this gives you sort of a big picture mental map of what's out there and how it works okay but that is going to bring the technical aspect of this video to a close hey congrats on making it to the end of this video now let's talk about where we go next from here obviously there's an infinite number of technical topics we could continue to cover but really we've covered the main five topics that i wanted to cover with you in this bootcamp series if we look at the chapter graphic remember i wanted to talk about design programming servers databases and user authentication now i know we only spent a little bit of time on each of these topics but it's really up to you to continue to specialize and learn whichever ones you're most interested in however where do we go from here well in the next video i want to give you sort of a big picture what i recommend as a few next steps you can take so both technical and non-technical things that i think will help you on your journey really i just want to share some big picture advice that if i had a time machine i would share with myself when i was just getting started uh with a career in web development as always if you're enjoying this boot camp series i'd appreciate it if you could share the link with your friends and family take care and i'll see you in the next one [Music]

Channel: LearnWebCode

Views: 19,686

Rating: 4.9621053 out of 5

Keywords:

Id: uXDnS5PcjCA

Length: 46min 41sec (2801 seconds)

Published: Mon Nov 30 2020