SFNode Meetup: Why JWTs Are Bad for Authentication - Randall Degges - 2018-01

first off I apologize to the organizers when I submitted this talk to to come here and give this talk they were like hey your title is like really like antagonistic like please don't antagonize people or something like that I'm I'm misjudging her I'm messing up the words but you get the idea anyways I decided to go with the original title anyways so I'm sorry guys but I'm telling you it's gonna be awesome so don't worry so the title of this talk is officially JSON web tokens suck and they're stupid now one other thing I'm sort of a casual presenter I sort of like doing things casually I wear sandals and I hate wearing shoes so what I did is I brought a bag of candy so the first 30 people to ask a question throughout this talk will get a piece of candy which is a pretty great guarantee I don't think most people are giving you that guarantee there's there's different kinds there's there's beef sticks there's like all sorts of stuff it's pretty good alright enough questions enough get it under control alright now real quick show of hands how many of you are familiar with JSON web tokens raise your hand pretty good number of you alright cool and raise your hand real quick if you are totally new and have never heard of this before and it's fine by the way you're gonna you're all gonna learn something awesome at least I hope so for those of you that are familiar with them I'm anticipating some of you are gonna get a little angry turn this talk which is why if you want to bottle that up it's bad for you so instead feel free to tweet hated me I really don't mind it makes it a lot more fun so feel free I have really thick skin it's not a big deal but anyways my name is Randall I ruin developer advocacy at this company called octa we're a security API company and the gist of what we do is we store your user accounts for your applications so if you're building like a web app a mobile app and API service we do like all the authentication and authorization and security stuff and we give you developer libraries in a bunch of different languages to let you log users in register them reset their passwords you know authenticate them things like that I've also been doing Python no tango mainly in the security like a space for many years now and yeah it should be fun so the first thing we need to talk about tonight is what the heck JSON web tokens actually are now you're gonna see this acronym JWT a lot it's just the short form for short form it's also pronounced jot so I'm just gonna use those terms interchangeably all right but basically JSON web tokens are really some JSON data that's cryptographically signed and that's it okay what people don't understand is that they're not fancy so a lot of people are like super into JSON web tokens they think they're really interesting but they're pretty boring they're just JSON data with some extra metadata crap in there so not that fun they're also not encrypted like 99.999999% of the time so you can encrypt them but nobody does now again the formula here is a JSON web token equals JSON data plus a cryptographic signature now you might be wondering what's a cryptographic signature which is a valid question the way I like to explain it is like this let's say I write you a letter so I type up the contents of my letter and I print it then I sign my name at the bottom so it has my handwriting on it and I send it to you in the mail what happens is when you receive that letter as you look at the letter you read the contents you see my signature you know who I am you know what my signature looks like and you say oh you know this is randyll signature for sure and so I trust that all this words on the page all these words on the page that were typed that those were also written by Randall so you trust them and that's what a cryptographic signature signature is just a way to show some trust for some data and so the whole purpose of jots really are just to prove that some data was generated by somebody else now the best second example I can give to you of this is whenever I go to the airport and I go up to TSA the end they ask me for identification I take out my driver's license I hand it to them and if you look at your driver's license right there's like your age your name your height all these variables value that's what the JSON data is sort of like and then the agent looks at that then they look at the card and they say well this card has all the right watermarks on it it has the state the stamp of the state of California sorry no it's legit that's the signature and so that's those the combination of those two things is what makes the jot jot everyone following so far man everyone just missed the opportunity for candy but whatever now here's the here's where this is gonna get fun right what happens when you Google JSON web tokens anybody know know everybody loves them there's like a million blog post no no we're not talking about that now what happens is you get you get results and there's a million blog posts YouTube videos tutorials etc that all basically say hey JSON web tokens are amazing if you're building a website and want to log users in you need to use them how many of you have heard this or seen this a pretty big number of you cool and here's the thing uh-huh pretty much all these people are wrong hence the the purpose of me coming here tonight I think it's fun to talk to talk about this now I feel like I'm crazy because not alike there's very few people that feel this way very few people feel that JSON web tokens suck if you look new stuff online you'll find some cryptographers and security people that are like these are horrible don't use them but for the most part everybody loves them and wants to use them including a lot of my co-workers and we argue about this constantly and I feel like a grumpy old dude so I don't want to lie to you the reason I'm here isn't really to educate you guys so much as it is to like like throw my opinions at you and hope that I can validate myself that would make me feel way less crazy so that's that's my personal goal for tonight now I think the the root of the problem that we're gonna be talking about today is that it isn't really so much a JSON web tokens suck it's more a problem that like people have forgotten how amazing session technology actually is this is something that we all take for granted like constantly so before we can get into the root of this we got to define some terms this is gonna be a little boring but bear with me and again if you have a question raise your hand or shout or something now the first thing we need to talk about are stateless shots okay they these are tokens that are entirely self-contained and contain every piece of data that a user needs to login inside of them now what do I mean by this well most people when they're using JSON web tokens they use it in the context of a login okay so let's say I log in from a browser you know into a website that website might look up from the database my name my first name my last name my email my date of birth all these things create a JSON web token with that data inside of it as JSON and then stored in the browser in order to remember who I am like to keep the session going right and that's what a stateless jawed is it's when that token contains everything about the user all their fields now let's see how this works let's say users logged in to a website and makes the request to say hey website let me see a page the website's going to get the request and that request will contain this JSON web token and so the website is going to validate the token using this cryptographic signature we talked about earlier the details of which are not super important it's then going to extract the JSON data from the token and it's going to say hey well Ivan your email all these things about you then it's going to use those variables to render the page and then send a response back to the user so they can see the page and maybe the page says like hello Randall or something okay pretty typical stuff next up let's talk about a stateful job this is the opposite of a stateless job a stateful jaat is a token that only contains a user ID okay it could be a user ID it could be a session ID just some like long random sort of arbitrary number basically this is what it comes down to and the way this works is like so the user says hey website let me see this page the website is going to validate the token again and it's gonna extract from the JSON data this ID it's gonna say okay your ID is 1 2 3 4 5 then it's gonna talk to the database like a MongoDB database maybe guy you're in here somewhere ok oh there you go shout out maybe you're talking to may be talking to postgrads or whatever the heck you want to use and it's gonna say hey who's the user whose ID is 1 2 3 4 5 the database is going to say well that's Randell here's all this personal info the website's gonna get my info from the database right from the query and then finally it's going to show the page now one thing you might notice is the difference between these two things is it in this flow there's a database involved right and so you know by necessity this flow is slower because talking to a database usually over a network adds latency so next up let's talk about session tokens this is sort of like the throwback old-school like early 2000s 1990s like way that people did web logging okay it's basically a session ID you know it could be 1 2 3 4 5 it could be a you know usually a long random number and that's the only thing that it is just a number it's usually cryptographically signed but it could just be a plain number and what happens when we use it is something like this so users locked into a website instead of a token they just have this number it so the website retrieves that number from an HTTP header which we're going to talk about in a minute and it finds what that number is your session ID is 1 2 3 4 5 the website's then going to talk to the database and say hey give me this user based on this info and then from that point on it's the exact same as the thing we just saw does this make sense to everyone so far the only difference here between a stateful jot and the session token is the format of the data so the jot is like a protocol which has other things inside of it and this ID where as what I'm talking about here is just the ID that's cryptographically signed making sense so far okay cool so next up let's talk about cookies so cookies are like a fundamental web technology that we all need to understand and I think they're super cool so cookies are really just an HTTP header field that allow you to store or retrieve key value data it's really all they are and the only thing you really need to know about them is you can only store about 4 kilobytes worth of data inside of a cookie now how do you create a cookie well when a user tries to log into your website and you want to store cookie in the user's browser what you do is the web server is you return this header called set - cookie and on the right side here the value of that header is just going to be key equals value that's it so in this case I'm defining a cookie called session whose value is one two three four five really really basic if I wanted to set multiple cookie cookies in the browser I could basically just add a semicolon at the end and add more key value statements there makes sense right pretty basic now when you're reading cookies so if a user has a cookie set in their browser and then they make a new request to your website how do you determine what cookies they're sending to you and the way you determine that is you parse out the cookie header so it's the exact same format as the one on the previous slide see the only difference is it's called cookie so on one of them you're telling the browser hey I want to store this information on you and the other one the browsers are sending it to you makes sense cool it is the body here oh this is the body of the request yes this would be like all the HTML or things like that all the headers I'm talking about here HTTP headers so they're not part of like the stuff you're sending back and forth from the tune from the server candy all right next up let's talk about local storage how many of you know all about local storage raise your hand okay sweet this is gonna be fun this is gonna be real fun then so I hate local storage sucks uh-huh I think it's really dumb it's basically it's the same thing as cookies right almost except the idea is that instead of storing it instead of requiring the browser to send it back on every single request and hiding it from JavaScript local storage is basically a pure JavaScript database that allows you to store information in the browser okay now now that we've covered the basics let this is my favorite part let's talk about myths about JSON web tokens yes we're gonna get to it in a second I don't want to spoil the surprise too early all right you get a piece of candy - it's good that was an easy one all right so let's talk about the myths now this is gonna take a while so strap in now the first myth is that a lot of people say JSON web tokens are easier to use than sessions how many of you have heard this where's Jen Wow not that many okay usually the hands are like crazy and people are cheering it's the same so let's talk about some facts so JSON web tokens the very first specification of this protocol when I'm saying sessions I'm referring to cookies with session IDs as the identifier so not using a token in a cookie I'm gonna elaborate on it more in a minute yeah just clarify so jason web tokens is a spec that was created at the very end of 2012 okay it never really got any usage until mid 2014 that's when it first sort of like the first blog post about it came out and when people actually first started to hear about it and start using it if you've ever implemented a site using JSON web tokens I'm assuming a lot of you have since you're using node and it's very common pattern in the node world you know that you need a JSON web token library to work with them and you need a lot of tools and understanding to sort of implement them now sessions on the other hand have been built into pretty much every web framework since the 1990s and they require zero effort to use so you know if you're using any major web framework working with sessions this sort of expected default behavior and is built into basically everything so when people say they're easier to use they're basically just wrong now here's the thing I am really really bad at keeping track of like scores in my head but I thought it'd be fun to score this so what I'm gonna do is after we go through myth I'm gonna say jots and you guys are gonna say zero come on come on zero and they're gonna say sessions you guys are gonna yell okay we can do this so next myth is that people say that jots are more flexible than sessions and this is actually really really interesting one so let's take a look at what a jot contains typically right as I mentioned before they're basically just blobs of JSON data which is true and they might contain something like this a user's information in JSON format and we all love JSON it's it's cool it's nice it's great whatever but when you're using a session and you're setting this data you are basically using form encoded data and so this is what this same information might look like in a form encoded format does this just make sense so you can convey the same information either way like if I was defining this and I was saying you know cookie : whatever and defining this stuff I could define user information in there and now the more advanced people of you in the room might be thinking well Randall is a total newb because jots actually have these other cool properties to make them way more flexible than session tokens for instance most jots have these two fields built into them one is called IAT which is short for issue dot one is called exp which is short for expires and the values you see there these are UNIX timestamps okay so these represent dates and times in future when this token expires and what's cool about this is this basically the same thing it's like on my driver's license I have an expiration date right if I show it to the TSA agent and it's like 2019 they'll say you can't fly it's the same concept here so JSON web tokens have this built-in expiration time and that's a really useful thing because if someone's logging in and identifying themselves signing them a set duration for that is a really powerful security tool to limit how long they have access to something question yes I'm sorry what was that oh oh yeah hopefully yes my timing is all off Yuga 2019 is a bad example oh okay that's good now let's let's look at sessions right they actually have an expires field you can throw in there so you can actually accomplish the exact same thing using a session so I'm just going to go ahead and give the point two sessions anyways because screw it I'm in charge now shots you guys gonna get better this is pathetic sessions okay this side of the room is way better than this big side for some reason I don't know what's going on you know the next myth is that people think jobs are more secure this is the big one okay it's a more modern protocol people really like using it this is what a lot of you like articles tutorials a lot of the the movement to adopt these things is really geared around this so let's take a look at this on the good side we've got the fact that jobs are cryptographically signed that's really really useful because that allows you to trust a JSON web token basically they can also be encrypted using this speck called jwe but like I mentioned before almost nobody does this it's actually extremely complicated to do this properly but it's technically a good thing on the bad side it's a very complex spec specifically the Jose family of specification so all the encryption the JSON web Keys all the other things that are like in the same like arena as this multiple vulnerabilities have been found over the last few years and there's vastly different support across all the different JSON web token libraries so I challenge any of you to build an app in Python for instance they use the Python JA library it can encrypt things and sign them in the same way it's pretty difficult to do that and then take that and integrate with a node app that has the same features built into it using one library it's pretty tricky and that's mainly just an artifact of the fact that this stuff hasn't been around that long and there's a lot of open-source developers still working on building proper tool now sessions on the other hand there's really just a lot of goods in my opinion so there cryptographically signed as well they can be encrypted as well most frameworks support this they've been around since 94 so they've been around for a long time they've been tested and things like that the specification for sessions is extremely simple there's been no vulnerabilities in this this method of authentication for ever and there's identical library support in pretty much every single web framework across every single language in existence so I'm gonna go ahead and give the point two sessions again so jots sessions alright cool session hijacking we're gonna talk about that later that's true all so the question if you can hear it is he saying that cryptographic signatures are not consistent across sessions across frameworks and languages and stuff as well and that's true however it's the same thing for JSON web tokens like you are not going to you need to know certain variables when you're implementing like logins and session management stuff so you need to know what cryptographic signing stuff is being used regardless oh I think the multiple multiple vulnerabilities and all the other things over the last few years and the general lack of support gives the ease of use or gives the the security advantage to sessions but does a good point and you get some candy there you go now the next one so how many of you are familiar the cookie consent law in the EU like you know when you visit websites and has that annoying banner and it's like hey if you're using this website we just want to let you know we're using cookies and like we're gonna track your data and whatever like press ok to be cool with that a lot of people think that if you store all of your your session information your tokens inside of local storage for instance that you are somehow exempt from the cookie consent laws in the EU that's actually a misconception though so the the wording of that law is actually different than what a lot of people think what that law actually applies to has nothing to do with authentication information so if regardless of whether you're storing people's login information in a cookie or in local storage or whatever that is not required to be displayed on your site that that banner the only time it's required is when a website is actually tracking you so using things like Google Analytics tracking tools to you know ad networks things like that and that is required even if you run the ad network stuff in cookies or in local storage it doesn't matter wherever it's running if you're tracking people you're required to show the thing so this is really just a misconception a lot of people have and because most developers using JSON web tokens are storing these tokens inside of local storage I'm giving the points to sessions because that's really lame now jots sessions all right next up jots prevent CSRF so how many of you in here are familiar with CSRF cross-site request forgery ok for those of you that aren't it's a little out of scope for this but let me just explain quickly so let's say that I have a banking website right like my bank comm slash withdraw if I go to this page there's a form and it really only has two inputs one input is the amount of money I want to send and then the other input is who I want to send the money to pretty basic right now let's assume for a minute that I am logged in to my bank website and I'm talking to my friend over you know instant messenger and they send me a link that goes to you know my bank comm slash withdrawal question mark amount equals a million dollars ampersand two equals you know attacker they're basically trying to trick me into transferring money to them and so I click the link not knowing that maybe there's a bitly shortened link or something whatever and so because I'm already logged into my website I immediately go to that page and the money is transferred out of my account that is what cross-site request forgery is it's tricking people in to doing things that they don't want to do without realizing it now a lot of people think that JSON web tokens can help prevent this pattern of cross-site request forgery and still let's talk about this now the truth of the matter is that this actually has absolutely nothing to do with JSON web tokens well it has everything to do with where your authentication data is being stored so if you're running a website and you're storing authentication information inside of a cookie then you are always going to be susceptible to CSRF the reason why is because you know if you're logging if you're logged into a website and the browser stored your authentication information in the cookie and someone tricks you into viewing a page on that website by the very nature of the cookie that brow your browser will send your authentication information to the website no matter what now if you're using local storage on the other hand you're safe from CSRF the reason why is because local storage purely works through a JavaScript API and so let's say an attacker sends you to this withdraw page with those parameters because your authentication information is in JavaScript there is no way for someone to trick you into making this operation it's not gonna happen you need to execute JavaScript code first however if you're storing your tokens inside of a local storage which is what most people using tokens do you open yourself up to something called XSS now how many of you are familiar with that cross-site scripting that's right so let's talk about that for a minute CSRF is actually really trivial to fix so in the node community it is a really popular library called CS URF in every other programming language there's a bunch of libraries typically built into your frameworks automatically to handle this from happening there's a really common pattern of preventing it but cross-site scripting is one of those things that's actually extremely difficult to prevent now show a show of hands how many of you have ever plugged jQuery CDN into a web page to raise your hand how many of you have ever plugged the bootstrap CDN into your website raise your hand a pretty decent number of people now I noticed not all of you raise your hand so there's definitely some Liars in the room because I'm pretty sure everyone here has done that you damned liars now that's okay I'm not gonna judge but it is what of this you've done it now here's the thing about this right storing any authentication information in local storage is just a bad idea and you don't need to you know trust me about it basically Oh wasp which is like the largest security sort of think tank online this is a quote from their Docs they basically say hey you should never store stuff inside of local storage the same applies to session storage by the way for those of you more advanced people and the reason why is again because it's you're storing your authentication information in the most dangerous place in the world which is JavaScript and what's bad about that well here's a real-world example of something actually helped an anonymous company with two months ago there's a very popular marketing company and they run you know an ad network right and so you embed their JavaScript tags into your public website and it runs and it runs and it runs on your page whenever you you load it and millions of companies use the software so what ended up happening is someone found out that they were able to compromise this javascript code that's being embedded across millions of different websites the reason why is because they had misconfigured their Amazon s3 permissions pretty common issue and so what that means is this if any attacker can run JavaScript code on your website including stuff has been included from bootstrap or jQuery or an ad network or any of the third-party providers your marketing team might use that code can run grab all of the authentication information out of your website because this is running in JavaScript don't forget and send that data to them so they can impersonate your users have their login information and generally do bad things does that make sense great so don't do that cool so jots sessions okay next up a lot of people say that yachts are better for situations in which you need to do cross-domain authentication and this is also a big one so how many of you have ever built a website where you needed to have multiple subdomains where a user stays logged in or where you need to authenticate across multiple other domains right it's a tricky thing to do and one of the problems with cookies if you've ever worked with them is when you're setting up your cookies they're typically bound to a single domain they can't just be like a universal thing like like with local storage for instance and so instead of me going to the trouble to explain why you why you don't want to store things in local storage since I just did that instead I'm gonna show you the proper way to do this using JSON web tokens and using sessions so let's say you have a website and it's publicly hosted it's just a simple static website and it's on dub-dub-dub so the user goes to that website and clicks the big login button all right well that website is just a static marketing website doesn't do anything so what does it do it redirects the user to the login subdomain so now the users on this login sub domain and the login subdomain is going to see this request and it's gonna say oh well let me just render the login page so it sends the user back the login page so the next thing that happens is the youghurt is the user types in their email and password and hits you know LogMeIn the login server gets that information and says hey this looks legit your email and password or valid I checked it against the database I just logged you into my my domain using a cookie so now the user is logged into the login subdomain okay and then here's the interesting part it's also going to generate a JSON web token that expires in 10 seconds okay then the login domain is going to redirect the user with a 302 redirect to the dashboard subdomain this is like being inside of the users application and what's going to happen now is the dashboard is going to get this request it's going to see this JSON web token in a query string in the URL it's going to parse that out it's then going to validate the JSON web token which contains a user session ID and then it's going to create a new cookie for the user so they're now logged into the dashboard domain as well make sense so far and then finally they're going to show the user the dashboard page and now the users been logged in now this pattern works across very large applications you can do this across top-level domains you can do this across subdomains but the concept is basically simple this is the best way to do it so in this scenario all of your authentication data is being stored in a cookie where it's safe no JavaScript can access it that's what makes it safe and you're using a JSON web token just enough so that you can basically validate one thing one piece of information the user session ID for a short period of time and this is like the real great use case to JSON web tokens have now have we been doing this the wrong way which is what a lot of people recommend we would basically be storing all the authentication data in a JSON web token in local storage and then just making a request from the users browser to these different subdomains sending that token along and that'll be bad does this make sense so far I know it's gone a little complicated because so far okay cool so with that said sessions are the winner because that's where we're storing the authentication data and so that brings the score to jots sessions six great yes they don't I'm sorry they don't get a point for that beer because here's the thing the reason I'm not giving them a point there is I'm trying to make a point sorry I know it's bad wording but I'm trying to make a point you could cryptographically signed anything and send it in a redirect URL a JSON web token is still inefficient for that which we're gonna talk about more a little bit later but there's a million ways to do stuff right the main thing about joste makes them cool is they're cryptographically signed JSON data but in this case do we need JSON data no do we need cryptic obviously integers yes cryptographic signatures is the real hero here and not the jots themselves but it was a great question now a lot of people also say that jots work better on mobile now i'm not like the context of this talk is i'm really talking about web authentication okay so logging into a browser I'm not gonna get into like API authentication with OAuth and open ID Connect because there's not enough time I'd be up here for like two full hours doing this but if you're interested in learning more about that after talk to me but basically in the context here do jots work better on mobile the answer is just no and the reason it's no is because on mobile devices if you're using a browser like WebKit or whatever it still supports the exact same cookies that everything else does and so there's basically zero benefit to doing this any other way so I'm just gonna shortcut that in and give myself a point anyways so jaws I'm just gonna go ahead and say zero and sessions seven there we go question yes oh I forgot I set it up there there you go oh you know what I'll give you two oh you got the first animal crackers you're lucky all right now let's talk about efficiency okay now I used to do a lot of like low-level low-level performance optimization stuff I'm sort of like an efficiency Nazi alright so I apologize in advance because I'm nitpicking here but let's talk about this so what I've done and you guys are all free to reproduce this I will publish the code on github after this talk or something it's really simple to do but let's say you use the JSON web token library pick any one of them alright and the only thing you want to store in the JSON web token is a user ID okay like one two three four five let's say so you create a JSON web token you get this long string because it's cryptographically signed and compacted and all this stuff is part of the spec which we're not gonna get into and you take the count of bytes in that string alright it will probably be something around like you know 128 something like that then let's say you do the same thing you just take the number one two three four five and you cryptographically sign it using the exact same algorithm and then you compare the amount of bytes in that string and what I will tell you is that the session that's been cryptographically signed is significantly smaller in terms of byte size than the token and this makes sense right because these tokens are using JSON which is more verbose than just a single string first of all but also because they have all these additional fields called claims and betim inside of them and so JSON web tokens typically have extra metadata embedded inside of them and since we don't need that in order to authenticate people it's just a waste of space now it may not sound like a lot of space let's say there's a difference of a hundred bytes here right but if you're doing this for a big popular website particularly if you have users in other countries where mobile internet is slower let's say then when users are talking to your website they're sending an extra 100 bytes of information over the network on every single request and that really adds up over time now again I'm nitpicking here but again I'm giving the point two sessions because I'll be damned if jaws are more efficient which they're not so jots sessions you guys are getting so lazy with this but it's okay we're almost done so don't worry all right next up let's talk about what happens when someone's account has been compromised okay typically when someone's account has been compromised you need to revoke the person's access right so if you leak your password somewhere for instance you need to reset your password same thing goes for sessions now let's just talk about the myth that jots are somehow easier to revoke then sessions all right let's take a look by example let's say a user wants to log in to a website so they log in and the website gives them back a JSON web token as their authentication information and that token lasts for one hour now what happens if a hacker somehow gets gets access to this token maybe for instance the developer was storing the token in local storage and maybe someones jQuery CDN got acted for instance right well what happens then is maybe the website detects that this person's account has been compromised because now all of a sudden there's requests hitting the website from Moscow and that's very unusual and so what happens well as the website they say well you know what this guy's accounts been compromised what's the fastest way to revoke his access well let's just change our cryptographic signing key they were using to crypt it off cryptographically sign all of our JSON web tokens and that will in fact work the only problem is that logs out not only this guy but everybody else in the whole world that's using this website because once you change the cryptographic signing key everyone who's using the site is using the same key and they're all logged out and that's a really bad experience I think we can all agree now you might be thinking something like this right like you are a noob I could use individual revocation list for something like this and you'd be right I am a noob but I'm not wrong about this now let me show you what I'm what I mean let's say you log into the website and say hey I want to see this page the website basically is going to check the database it's going to grab your your JSON web token it's gonna query a DB and say hey database has this token been like revoked yet yes or no then the database is gonna say yeah it's been revoked and the website is going to say get out here you can't access it now the problem here is that while this does work a revocation list does work when we're talking about tokens G does anyone see the problem actually chance for candy the problem is we've reintroduced the database and that means we have latency and again we remember we just talked about the fact that jots are larger in size and less efficient than session IDs so not only are we wasting bandwidth now but we're also wasting latency talking to the database and so we've we've solved the problem but at a net loss to our efficiency question yes the question is you that I am completing the term session with the usage of cookies which is fair I'm sort of throwing things around interchangeably to keep it simple but in reality what I'm talking about here that the pattern I'm describing is the difference between using a JSON web token whether it be in local storage or in a cookie or just storing a session token itself like just an ID the scripture graphically signed in a cookie or in local storage and so comparing those two things together this is just more efficient because it's smaller and doesn't have the the extra weight inside of it but it's a fair question but it doesn't actually affect the outcome here either way you have the same result oh okay so now the question just to expand on the question he's asking so everyone can hear he's saying well also part of what you're implicitly assuming is that the way that the the person building the website is storing the sessions themselves or is in some sort of like centralized location right you're storing it in a database right or you're storing in a cache like memcache or Redis or something like that and you're right but what I'm showing you here is the fact that if you want to have a central token revocation list to properly revoke people's tokens you need the exact same infrastructure yes that is correct that is correct I'm actually about to talk about that in the next slide but here's some candy question oh yeah so so his question is a comment is like when you're storing things in a database you always need to worry about things like sequel injection and things like that which is true but we're running out of time so let me move move along here but all I gotta say about this is what the hell because basically if you're storing tokens and you want a central place to revoke them then you need you absolutely need the same infrastructure you need to manage the session anyways and it's just less efficient and so we're giving the point two sessions now JSON web tokens sessions cool next up jobs are easier to scale this is where we're gonna talk about some stuff now the good thing about jaws is that they can be validated locally without any external database access this is really great right just by doing some math which is pretty cool I'm the bad thing is this only applies to the stateless jots okay so only if your job has all the user information inside of it is that true if it doesn't you still need to talk to a database to get user information and that requires more bandwidth on every single request now let's talk about sessions they can you can use different types of session caches server-side to speed up access right this could be local memory could be Redis memcache a database whatever it requires less bandwidth for your users as well so the user isn't like sending their data back on every request you're getting it across your network the bad news is that there's always some sort of database your cache centralized that you need to retrieve the data okay now I think well one thing I want to mention and this is a little bit of my opinion right but if you're building a website you are going to have a faster internet connection than your users guaranteed there's no way that if I'm on my home laptop like making requests to your website that like my internet somehow fast than Google's data network or any of you if you're deploying your applications on Heroku Rackspace Google AWS whatever and so in my mind it's faster and a better experience to push the more heavy data lifting stuff onto the server and not make the client do it but what I'm gonna do is I'm actually gonna show you the proper way to scale out session backends which is what he was sort of talking about a moment ago in three simple steps now in the most basic example you have a website maybe have a couple hundred users and when a user visits the website you talk to the DB and say who is this person they tell you and then you show them the page this works for a website that has up to several hundred users no problem now let's see of a website that has several million users maybe even five ten million users whatever it's all pretty much the same you say hey website show me a page many times concurrently right and then you talk to a cluster of databases now these databases they could be a cache it could be a memcache they could be reddest they could be whatever the heck you're really into and you basically just hash across all of them they give you their answer and you return it this is what most large very large companies do today works absolutely fine I run a very popular free api service that does over 30 billion requests per month right now just FYI and I'm using a single Redis instance for this so it doesn't require a lot now let's talk about super advanced session scaling when you're super advanced and you're huge you can basically handle things by geographic location so send your users to the specific data center or wherever cloud location you're using that is physically closer to them and then have a cluster of caches within that location to store their cache information you can do this via a bunch of different methods and again this stuff is all fairly standard for instance in the Python world if using the Django framework there's tools built for all of this stuff and no there's a lot of tools to help you do all this stuff as well on most of this today is like a one or two line DevOps style thing to provision a bunch of like ElastiCache instances for example and so that makes this very easy to do to scale it up on the back end and so I'm going to go ahead and give the point of sessions we're gonna skip yelling it out right now because we're short on time the last point I want to make okay is that jots by design have stale data this is by design one of the principles in this security world in particular is caching is bad okay so whenever you're building a secure application cache is your enemy because stuffing caches are designed to be out of date by design right and so if you're using out-of-date authentication information or authorization information to check someone's permissions that is inherently bad now a lot of people just don't think about this when they're using tokens and so the implication is that well let me just show you so I log in and I have a token right and then at some point I start doing bad things and so the website administrator says hey Randall's acting like a jerk a jerk revoke all of his admin access the problem is that I can still be a jerk because if the web server is validating my JSON web tokens locally and not using a centralized cache right then I am still able to get away with things until my token expires and a lot of people don't really consider this effect when they're using these technologies so I just want to point that out and so because of this and because authentication data is a critical part of what security is I'm going to head go ahead and give the point two sessions because it's just a lot simpler and they are forcing you to take the right approach to designing this from the start now we're almost at the end I promise I'm gonna be off in one minute you're you might be wondering well how should I use these things right and that's a fair question there's two ways way one let's say you're building a download website okay we download videos maybe it's YouTube downloads or whatever so the user goes to a website and pays for file and says I want to download it the website's going to generate a jot for them that lasts let's say in one minute and it has information in there about who the subscriber is or whatever then the user is going to be redirected to a file server maybe downloads Google com whatever to actually download the file and that file server can be really simple now all it needs to do is validate this token and then let the user download a file SuperDuper simple now the key thing here is that the JSON web token is being used a single time for short duration so it only lists for a short period of time okay the next C schist is when you're doing password reset so let's say the user wants to reset their password the website says okay and it sends the user an email with a link and that link contains a JSON web token and that JSON web token expires in 30 minutes so the user goes to their inbox clicks the link and is back at the website the website then just validates this JSON web token and if it's valid this says well hey it's been less than 30 minutes you obviously have access to your email account so therefore you are allowed to reset your password and then it resets the users password pretty cool and again the key things to remember here this tokens being used a single time for a short duration these are the keys now I've said that phrase twice now and that's really the only acceptable way to use it is one-time usage for short duration now you might be wondering why the heck are JSON web tokens so popular if they really suck as bad and the answer is that it's sort of my fault but also sort of everyone else's fault in the security community so the main problem is that back in 2014 people in the security community even today we don't get a lot of new stuff like for the most part like cryptography hashing algorithms all these things have been making very tiny little improvements over the last like 20-something years things haven't really changed a whole whole big amount and so when new things come out the first thing all of us do is we're like oh this is awesome let's find a good use case for it and it just so happens that a lot of the security as the service companies my company included sort of jumped on the bandwagon of promoting this stuff right and so we wrote a lot of articles about it like here's one interesting way to use JSON web tokens we think they're cool check it out and other companies started to hop on the train and before you know it what ends up happening is sort of funny it turns it turned to JSON web tokens from a technology into a marketing tool and the way you can verify this is go to Google type in JSON web token hit enter and what you'll see is out of the ten results on the first page eight of them are actually marketing links which go to a sonic ation as a service company which basically teach you how to use it to try to sign up for their service and what's happened is over the last few years has become the single most successful marketing tool for all authentication companies and so basically today the reason it continues to be popular is because it earns a lot of money which is not necessarily a bad thing but the bad thing is that it's just a lot of misinformation and not sort of an unfortunate side-effect of this phenomenon so my call to action is I basically want you to stop using them so please do that thank you and yeah this is my info if you want to get a hold of me and thanks final question you can but you lose all the you lose all the benefits there's no extra benefit want Kenny we'll talk after they go they go [Applause]

Channel: SFNode

Views: 11,891

Rating: 4.717514 out of 5

Keywords: Node.js, SFNode, JWT, json web tokens

Id: GdJ0wFi1Jyo

Length: 49min 27sec (2967 seconds)

Published: Sat Jan 06 2018