All you ever wanted to know about JSON Web Tokens

[Music] thank you [Music] thank you [Music] [Music] foreign [Music] foreign [Music] [Music] thank you [Music] foreign [Music] foreign [Music] [Music] foreign [Music] hey well um good morning or good evening or good afternoon depending on where you are in the world um Welcome to our live stream on uh JWT Json web tokens all that you ever wanted to know assuming there's something you want to know otherwise you wouldn't be watching the live stream um so let's get started uh I guess I'll introduce myself my name's Robert Haynes I work in marketing for nginx in technical marketing I did used to have a proper job a long long time ago as a sys admin but I've been mainly talking and writing about technology for a good few years now I'm joined by Teemo say hello Timo hi Robert uh hi out there my name is Timo Stark and I'm working as a product management engineer for nginx and yeah glad to be here as Robert I worked as a sys admin and web developer engineer before my job at nginx um I'm with nginx since almost two years now and we are glad to be one of the Hoster of the show tonight should be fun um just a little bit of housekeeping if you're watching us on the YouTube live stream you can leave us comments and ask questions which we'll try and get to as we go along we'll be flashing up from time to time some handy URLs and we've got a bit of video to play I think you'll be able to find all the information you need following up from this this live stream in in the resources we put on screen there's not going to be anything super complicated to worry about so um let's just get going so the reason we're having this this conversation today um is because one of the in the in the most recent release of nginx plus there's some enhanced uh Json web token JWT jwe jws functionality and I was fairly new to that that space and I got team I've I've talked to Timo and got them to explain it to me and I thought actually this would be really useful to explain to other people too assuming there are other people with the same kind of questions as I have so we thought we'd repeat the um repeat me badgering him but this time for an audience um so let's let's start with this whole JWT jws.jot thing so what what's going on so we've got a we have a Json web token but then I see about six different varieties of of tlas for it so can you give me like a quick explanation about what the various different words mean just to get us started right sure um I know it's it's sometimes a lot confusing um so like how to come together with everything what is the job adjacent web token what is the signature what is an encryption and then you have other stuff like open ID connect and oauth and people think it's the same it's a different it's um that's a lot a lot of different things came together to make this whole ecosystem fly and something that I haven't showed to you Robert but I have prepared that for or digged out of my magical link resource list um for this audience today um there is a video from nachikamura that's the chairman of the open ID connect foundation and in five minutes he explains very well what are the difference between oauth and open ID connect and this is a very important understanding a fundamental understanding what is open ID connect and what is oauth how they play together and what are the fair differences between those two things because everything that we will talk about after that like what is a Json web token what is an encryption what is signature what is a barrel header that is all on top of this open ID connect in oauth um standards so that's why I like invite you to lay back and enjoy the the next little bit of a video um as it's it's worth it so have fun hi I'm natsakimura the chairman of the open ID foundation and the senior researcher a number of research institute today I want to talk a bit about the new identity protocol we are building open ID connect an identity layer on top of Earth 2.0 but before diving onto it I need to Define identity which we often talk vaguely luckily itut and Isa has defined it in the I.T context for us it is set of attributes related to an entity to understand this definition we have to understand the entity identity model entity is like us human being or machine service whatever but we don't perceive entities directly but indirectly through various attributes about the entity like he has blonde hair wears glasses six feet five inches tall and so and we want to express ourselves depending on who we are talking to by controlling what set of attributes identity we show your identity to your friends and identity to your boss are naturally different so we have multiple identities May are said to have typically a few identities like work husband father and women have a lot more we pick and choose which identity we use depending on the context the same holes for websites you want to use different identities depending on the site you go to get better service that's the identity layer and without Neti connect we have chosen to build it over all to that all this is often called authentication as well but you may ask why not just off Facebook does the same with all don't they well not quite oath itself has no notion of identity authors and access granting protocol also known as delegation Alice granting access to Betty's profile data to Cindy does not mean that Alice is petty no Cindy is Betty unfortunately though many services make this mistake and make it easy for service to impersonate a user Facebook's case is different they don't use auth for authentication that is but have built an extension called signed request which is essentially the same as the open ID connects ID token except for the fact that it works only with Facebook as the identity provider and the signature format its propriety while open ID connect works with multiple idps and uses itf's Json web signature standard in essence what it does is to provide the websites who got authenticated well when and how it was what attribute he wants to give to you and why all of these defined in an interoperable manner that's open ID connect it's interoperable simple and mobile friendly secure and flexible to be interoperable we have to define a standard way of requesting and responding claims so we have defined standard Scopes a method to ask for more granular claims ID token and user infinite point from which you can get the attributes as well as the translated tokens it's also very simple it is json-based rest friendly in simplest cases it's just copy and paste to implement a simple relying party and mobile and apps friendly because that was an explicit design principle and thanks to Earth too its security model can scale all the way up to extremely secure spanning from ISO 29115 level of assurance 124 leveraging on crypto and other techniques it's also very flexible you can make a granular request through json-based request object which makes data minimization easy to return the claims you have the choice of aggregated and distributed claims with different privacy characteristics open ID collect not only supports large identity providers but you can actually have your own identity providers for example you can choose to use a dedicated identity provider on your phone current status of the specs are that they are waiting for some underpinnings such as Jose specs and web finger go final once that's done we can finalize open ID connect and put it into the final membership port in the meantime people are implementing current draft right now 14 Solutions are performing interrupts encompassing over 120 feature tests so start building open ID connect now [Music] well that was very relaxing I feel like I should have been lying back with some cucumbers over my eyes while that sort of soothed me into but I I think I got all of that so in the middle there is is this idea of a token right and that's that's that's the that's the core thing is like there's a token and in that token we put data fields which we call claims is that right yes so that's right so yeah as we as we saw in the video um we have the auth 0.2 protocol and the video is almost seven years seven years old as the oauth um or the initial OS draft or the or specification as well nothing to new um so all the 2.0 was released back in 2012. so um and the open ID connect one this video was from 2013 so a lot of things at the end are at this time we're in draft mode like Json web token signature um all that stuff this is all done right now so seven years eight years later um this is not a draft anymore so this is definitely something um widely used out there and so and that's exactly what you have asked all this like things with tokens and claims and data um so in very at the very first we should pick this up from the video and talk about this identity piece and this authentication um part that we want to authenticate at a specific or for a specific service right yes that is a that is a usual thing that's around on the web for longer than 15 years that we have to authenticate for something we want to use right so this is common like login within username and the password on the website um there you have J session ID represented in a cookie I mean that's that's all fair that all done that's something we are probably very familiar with uh so this is this is definitely nothing new so but the the fair question is why do we not using it like today or why do we need oauth and open ID connect yeah why can't I just log in with the username and password and get like session cookie what's I mean that's that's what I've always seen before in the dim and distant past what's what's changed and why do I need this new thing so one reason uh to me it is is one of the best reasons you can imagine off is like given you have a very variety of set of different websites and services and you have to log in and before you can log into a given service you have to register first right so I mean to register for 150 whatever 50 25 services each and every time with your username your password your email address with like all this all this stuff so that means your your data your personal information like your email address your username a password will be stored at the vendors architecture or at the at the services architecture in a database and at this point you're not aware of okay how they treat my data will the password be sold it will it even be encrypted will it may be hashed so what they're doing with the data so this is and with with like open ID connect or oauth it is this is something from also explained very well in the video we have with all of this this idea of a Federated identity right so that means I have something that is an identity provider and most people can think about it like in like an active director or held up in a very very far sense um it's like in storage of of identity information so that means my identity provider knows who I am so that means I have my my username and my password stored at the identity provider and then I can log in at the identity provider with my username and my password and then the identity provider will take care of the authentication initially and then issue a token okay right and this token can then be shared and this is why the open ID connect and auth part was so important beforehand this one can then be shared with another application or service right so that means you have to register once add your identity provider um and not like a hundred different times on on each and every service okay so I go register with I go reg I go authenticate with my chosen authentic identity provider they give me a token I turn up to my web service and I hand over my token and say here here's proves who I am how does the how does the service I'm connecting to know that the token I've given them is is valid and and actually proves who I say I am well how does that bit work what's in that token that tells the tells the service that I am you know I'm authenticated right um to do that let me just hold over and because I could create tokens all day you know I could just like the Json text file oh let me see I fortunately accountable for real reason not share my screen um but let me explain that so what you said yeah you can create a token um if we're talking about a token um we can we can talk about something that is a Json web token I mean that's the whole that's that's the title of this webinar uh or this live stream so adjacent web token is defined in in its standard and it contains out of three different parts so first part is the header and second part is a payload and third part the third part is um the signature bit so okay when talking about signatures um we're like talking about some cryptographics and things but I will try to make it like easy to understand for for for you and maybe all other people that are not too familiar with open with uh cryptography um so let me let me explain it in an unusual in a usual Common Sense what is a signature all right so given we have a token the token will be signed by our identity provider okay heading over to us to the application so and now as you said the application can trust the token fair enough but shouldn't trust the token by itself I mean we need to prove that the token was not manipulated right so it means by by many playing the token we can think about of changing username and password I mean it's the same same idea that cookie hijacking where you can simply edit some data into cookie and type in hey I'm using XYZ or I'm an administrator whatever that will just work yeah I mean I can use I can I can grab the grab a token for somewhere and change it to say that I'm I'm I'm Timo not not me yeah and and present that so what what stops that right um the signature of the token stops exactly this and it's like you can think about that the token issued by the identity provider will be signed and the signature is like a digital proof of the identity provider and what it what it contains is the whole data like the header as well as the payload and the payload has been very very important part because the Scopes you have like mentioned earlier means you use a name an issuer maybe your roles that can be used for all three or for for authentication or authorization later will be part of the payload and what they will do is they will create like a checksum or an hash of the header and the payload and this is that a checksum and this checksum will be signed within with cryptographical material with a private key okay and this key is just known to the identity provider right the private key so that means we have a token and that will then be sent to the application and on the application side this is this is the novel technique of of web crypto or general cryptography on the the application site or on the nginx side we have something that is like a a set of public keys or the public key of the identity provider that is publicly known there is no secrets in it but what we can do is we can use the public key to validate the signature that was created by the IDP earlier on so that means with this technique we can assure that the token or more important the signature of the token still or is still valid so that means if the signature is still valid nobody in the mean or in the middle between the identity provider and our application has modified the payload or the header of our Json web token so that's why uh you know hey this token was not manipulated it is still the same it is still the same payload the signature is still valid okay so go ahead but I mean we're talking about this in a in a way that this is normal or this is like um like in living a living standard all over the internet trust me I've seen a lot of applications in my life that like trust tokens and what they do is like they use it and with it with your own implementation if you implement it by yourself I mean that's the cool thing on open ID connect and all of you can use an implementation of those in a Java application Python and PHP node.js doesn't matter to work with Json web tokens right so a very very very important thing here is that you make a bullet on your on your notepad saying hey anytime I do a custom implementation of JC web token I must validate the signature absolutely important so that way I can I I I don't have to I get a I get assigned I get a signed token that I can't alter and then I can present it to my service which has the public key of the of the trusted identity provider and because it's signed and they have the public key they can check the checksum and if it doesn't work then they know I've I or someone else has fished around inside it and changed changed values in the payload right gotcha so correct but that's just is that am I am I right in thinking and everyone on the stream should be shouting about how I don't get this if am I right in thinking that the it's signed but that doesn't mean I can't I can't see what's inside it so I can still investigate the payload is that right so I've still correct I feel kind of plain text and from in the in the browser context so if I have if I have something something nasty running on my browser because I've installed all my my grandma's installed five of those different toolbars and there's some some various processes going inside of a browser or some compromise in my API um system that all of that data although it's I I go I authenticate I get my token back I've got other information about me in there and the claims like my ID or you know um that's that's plain text um and then when I send it there okay it's it's guaranteed not to have been altered because it's signed but it's still visible is that is that how it works um correct so this is like leading to the to the idea of how to work with a Json web token after that is that is issued so um a couple of a couple of words about this and techniques um about like how to work with Json web tokens so you're Point number one you're totally correct adjacent web token is in general like if it's if it's sent from some back end to your front end or to the service uh as seen in the in the video it is basically a Json web tool is a Json structure so it is per default not encrypted it is signed but sign means sign not encrypted and what it is sometimes it is base64 encoded as said it is base 64 and coded it's not a cryptography you can simply decode base64 data um without any without any problem and so one one rule of thumb is what we already mentioned is be careful where you store your Json web token I mean having a Json web token in a cookie I mean that's still a valid thing um you can I saw that that people like storing a Json web token as a cookie value basically for encoded um in a in a in a session cookie that okay that that works um but make sure that this cookie is not like accessible from from JavaScript right so make it HTTP only make it secure because then it's the same same idea for for other authentication cookies if it's accessible from JavaScript if you have an excess asthma durability so cross-site scripting vulnerability on your machine on your on your um on your website it's easily like piggable by an attacker to get the token out of your um out of your cookie so okay that means if you if you if you need to store a Json web token a whole one in a in like your your browser in the cookie make sure it's secure and it's HTTP s or HTTP only and one more word about like token in the open ID connect world or the oauth world we have three different ones and this is very important to know we have an access token we have an ID token and we have a refresh token and the access token isn't usually this part that we want to share with our application okay it does it can be so that's important it can be a jot or Json web token but it necessarily it can be a something something like some session identifier as well so this as a as a side note do not like require an access token to be a job it can be a judge but there is no need to to be one an ID token is the thing we are usually take as a job as a Json web token with all the claims you have mentioned like username email address maybe some authorization groups address a lot of different things so we should take care of this one it can be shared with the application but be careful with with the things you're like doing and last but not least is the refresh token refresh token is a very very very interesting thing when it comes to open ID connecting auth because when we think about session lifetime right so we're logging in the token has expiration time so if you need to ask about that I mean do these tokens last forever or is there a so normally you say you have a long lift token which is the access or ID token um so they will have a session time for around let's say an hour 30 minutes I have seen five minutes and depending on on on the settings configuration settings on the identity provider but there is a special claim called exp and this shows when the token will be expired so that means somebody grabs a token from somewhere and use that after the expiration time it cannot be used it will not be valid anymore even if the signature is still valid the tokens has expired cannot use it anymore all right so let's go back to the refresh token a refresh token is something that we call a Long Live token it can be valid not like for 30 days I've seen applications configured the refresh token valid for 99 years which is a lifetime so that said a refresh token is a very very important thing to having like to store securely in your infrastructure because a refresh token can be used to issue a new set of ID or access token after user has successfully logged in at the identity provider so this means with a refresh token with a valid refresh token that is not like revoked or anything that's valid you will be able to create as many ID and access tokens on an IDP you want for a given user that belongs to this refresh token that's why another bullet when you notepad never ever under any circumstances store your refresh token in the front end neither in a cookie or in local storage or is it a hidden text field or whatever you can imagine this thing has to be in your back end securely stored somewhere not accessible from from anybody that's like um that should not have have access to this it's very handy in in mobile applications so that means it will be like if you log into a mobile app like a native app on iOS or Android it is some or most of the time they keep the refresh token internally in the storage um and then they use this refresh token on the app startup to create new token pairs um to connect to the to the backend services so that's a refresh token and this is definitely something you do not want to share with others okay okay so let me just let me just summarize where I think I am with my understanding so far and then we can work out what left to explain there is so this whole system works on me I or something I identifying and authorizing with a third-party service of some sort that then issues me with a token that's signed using the you know it checks on the the contents the the key claims part which is where all the juicy information is gets checks under the signs so that I can't alter it um in there are things like my you know maybe some my role my my username other information and then expiry time of how long this token is is working for I then present that to the web service of my choice which has to be configured presumably to trust the the identity provider that can then take a look at the token it can obviously see inside the token to see who I am but it can also verify that that token has not been altered by me because it can use the public key of the oauth provider or the authorization provider to to validate the signature correct and everyone has happy and I can also potentially have a very long-lived session if I want to but it's pretty much under the control of of the whoever's building the app um that still brings me back to the fact that that that um that token is flying around the internet I mean presumably usually in a in a in a TLS encrypted session but um there's no guarantee of that I mean it probably is but it's it's kicking around in plain text um in various places it's open to inspection by anyone doing like man in the middle attacks on SSL it's look it's visible to you know things that decrypt um decrypt sessions and re-encrypt them in infrastructure but my information's in there and if I want to transmit anything like sensitive do I not want that the actual payload to be invisible to anyone even if I it's unalterable should I should I be I mean I'm not sure I feel so good about that is there right is there is there encryption that I can add on top of this uh yes so Jason Webb encryption jwe is another so password jws signature e is encryption jwe um the jwe is is around for a long time and it adds a encryption capabilities to the like Json web token standard okay um so that means you can encrypt you can encrypt them and given Json web token uh it can like carry around on the token fully encrypted so that means even if you re if you're able to like consume or see the token you cannot inspect the values in the like inside of the inside of the token and I have one problem here with sharing my screen so that means I've checked my permissions and I will be back in 30 30 seconds Robert okay no problems so there is um one of the things that uh we have is a an old blog talking about a lot of this which is probably worth taking a look at um I think we can get the URL flashed up on the screen now look at that we've got we've got the best producers here um this is a Blog written a few years ago that's just been updated slightly to reflect some of the newer newer technology I found this really useful it has a really good um a good description about the structure of a of a JWT and and the signing piece it doesn't cover the encryption um part because at the time we wrote the blog and we didn't have that that functionality and it wasn't widely used but this this blog gives you a fairly fairly good um explanation about what we've talked about so far um hopefully everyone's sort of following along um so we've got to the point where we have got I think I understand I authenticate I get a token I can't alter the token because it's signed as long as the web service provides is the web service I'm connecting to trusts my my authenticating service then I'm good they can validate that I haven't messed with it and now we're going to talk about how how it can be encrypted so that not only can I not necessarily see what's inside of it but but neither can anybody else on its Journey from my device or my whatever whatever's doing authentication to the service provider um and I'm guessing that we create our token and we sign it and then we encrypt it is that correct yes that's correct um yeah I've just checked my my settings but for whatever reason I'm not able to share um I think that's a it's easier on my side um so in the while I'm explaining uh maybe you can you can just open the the latest nginx blog um I think I can probably share my screen let's see if I can make my own screen sharing work uh screen share screen um I can share screen [Music] two I can see on a Chrome tab look at that a very very large amount of information are already around on our on our website um so that that is that is that would be good for others to like reflect this this live stream and read a lot about it because it's it's a lot of information um to cover um so if if you have a chance to open the open ID the um r25 release block okay the r25 release plug hang on one moment for anybody out there if you're a key it's like a simple Google search for nginx plus r25 release notes um that will bring you straight to the there you go can you see that um and let's see if I can make this stream yard that's the release notes that I can actually stop sharing that screen I can share this screen here share this screen screen share a Chrome tab and the r25 announcement blog um us this has all oh look at a beautiful picture right is that what yeah there you go if you can make this a little bit bigger like Zoo expand that to that's about as I can probably zoom in and see right here as well if that'll help me zooming in or not let's see if that let's go go is that better uh look what yeah you've got perfect um so it's a lot easier with this with this picture um as it is like it's just it's it explains more than I I could say in a thousand words so jwe which is the Json web encryption is a Works in in a different in a different way so what we can do in this case and this is not a must this is a can but I saw that widely used out there with insurance companies and Banks um because maybe one word about a use case when you use it an encrypt the Json web token so they have an identity provider and they have some sort of data for example um very very sensitive information about your insurances or about your credit card it's like a credit card number or transaction ID anything that you definitely do not want to spread with others right but the identity provider knows something about this at the time you log in and they need to carry that along with the token because the token will then or could then be sent to to a large amount of different services in their backend apis so but they definitely do not want to have your my insurance number or other very sensitive yeah personal information readable so what they do is they created a signed Json web token with all this information the payload your you like in the Scopes we have mentioned like username name email whatever and what they do is they use this sign Json web token and this is what we see here in this diagram in this second layer we have a signed Json web token with header payload signature as ciphertext or as if you want payload of an encrypted Json web token so that means that the payload or this the text that will be encrypted is a completely fully signed Json web token and then we go one layer above into the jwe layer okay and what we do then or next is we encrypt the we encrypt the ciphertext or the payload of this encrypted jwe with symmetric or asymmetric cryptography and that like then we can send it for example to nginx as an encrypted Json web token or as a jwe and what nginx can do we can decrypt the token with given key material um if that's if that's not understandable I can explain that in a minute a little bit better uh a decrypted extract the sign Json web token this jws out of the encrypted token verify the signature expiration date and all that stuff and use it as an authentication if you will for other services but the important bit here is we never shared sensitive information with the public audience because the at the the IDP encrypts the token send it over the wire in our application maybe in a cookie somewhere send it with a request to nginx or to your application it will be encrypted or decrypted in the back end and then we extract the sign token and with all the with all the sensitive juicy information in it um but it's all like back-end site it's never client-side so that's the that's the like an induced case of of encrypted encrypted uh so now I can put anything pretty much anything I like inside this token because it's been encrypted and therefore it's you know it's only going to be decrypted by someone with the key um of of that so that that means I can store as you say things like uh credit card numbers or that maybe that's a bad example but like claim IDs or you know personal information a medical medical IDs and stuff like that can go inside this token and I can I can present that to my application as long as that has to both have a decrypting key to be able to decrypt the actual con thing and then it presumably has to have the the signing public key to make sure that it hasn't been altered that gives me kind of two layers of of both I know that it's been encrypted and it's invisible and it's um and it's not and it's not been altered because it's been signed as well correct that's and so do I do I normally throw this in like it I'd normally put it in like a and the oauth cookie or something like that would that be the normal place that I'd place this kind of information um yeah I mean it's it's it depends on the like on the way you implement an oauth open that you collect flow and but in general speaking what you can do is like you can put the like this encrypted token in a cookie if you want it makes it easier like to send it to send it across with every with every single request to your backend and then then you can you can work with it another idea and that's that's what we do at the in the nginx reference implementation for the open IV connect is we have something that's called OPEC session cookie or all black sessions so that means we we think that in in a like an unusual and unusual zero trust environment we do not want to share more information was defrauded and absolutely needed so given you have a little Avatar ik in your web application you need maybe the username maybe the first or last name in in some some sort of a some sort of a cookie so we can do this but the full ID token that you need to authenticate with all the necessary information we store on the nginx in the back end and create a session reference which is like a random random session string I can normal session ID and we create an HTTP only cookie and send this to the client so that means anytime you send a request to nginx yeah over the maybe the proxy to your backend Services what nginx can do is we can read the session ID which is totally random which is not contained in this session ID does not contain any useful information it's a random string but we will take this session ID look up in the key value store which is kind of an in-memory database on redis um add extract or get the token the ID token we've stored previously out of our in-memory database attach it to the request and send it to the backend so that means we have another another layer of security building um and the original idea to this I mean I I have done a presentation at nginx conference 2018 about it especially this bit because I was required to in to create and service that was exactly doing this not storing any or not sending any token information to the front end it was required for idea security so this was like the this was this hour one on the birth date of the of this user service this optic session session IDs so that means this is another another idea or another another bit you can think of do I really want to like or do I really need to send a whole cookie or a whole token to the front end no matter if it's encrypted or um just signed or can I have something as a proxy server like nginx in the middle that will keep my token securely on the backend side so not visible from from outside but can attach the token anytime I make a backend request um over the proxy so that means the packet can authenticate with the bearer or with the token I will come to the better header in a second um but I don't have to carry that along with a cookie another another important video is completely technical it will it will like make your requests the data your carry around the wire um yeah we'll make this request more lightweight because I was working for for a car for a car company they the token they were just huge like 125 case sometimes right a lot a lot of data in the payload um which is not recommended but you're totally able to do so you can put whatever you want in a payload so in this in this blue middle part of the picture um header payload signature you can dump whatever you want in the payload make it as big as you want nearly um but it's not really recommended is you have to carry this thing along the wire that makes the requests much bigger yeah okay I mean we spend quite a lot of time trying to reduce the the ground of the metadata size the header sizes in in buying by uh you know the various compression techniques that come out in HTTP 2 and 3 and stuff so I'm guessing inflating my header size is not is not super super cool for a lot of people but I guess I can see for some apps how that would work so just so we've talked a bit about nginx um obviously the focus is more about JWT but just to be clear so nginx can support um all the different flavors of of JWT and jwe so we can deal with signed we can deal with uh encrypted and we can deal with signed and encrypted which I think we've got is that called nested so you can we can come with all those those types and they can be set up to we can be set up to decrypt and validate the the tokens before we either and extract the data from them until um before we pass that to a back-end service so that means I guess that means you can have you could in theory implement this layer of of increa this layer of authorization when your app maybe doesn't support it or you don't even want to support it you can you can potentially just be the authorization solution for a bunch of different Services behind nginx who will look at the token we'll validate it we'll check that it's it's you know that it's in date that it hasn't expired um and that it's valid and then pass on credentials or other other values from the from the from the claims section from the payload to the downstream service in pretty much anywhere we want that's um that's fairly useful I think I think I understand everything so far cool um and I've just shared a link with you Mark um Robert on on slack and this is like the the link to the guest I I created some some sort of a um collection about like how to work with signed and encrypted tokens because while I did my my testing and presentation about like the r25 r24 we introduced a symmetry crypto for Json web tokens I played a lot around with how to create tokens right how do you validate them so and that ended up in a in this gist and I definitely want to share this with um yeah with you and this especially with with all the the people like around um let me scroll a little bit into this so yeah we can absolutely I'm just reading it myself so this is how to generate so I can be I can I can become my own auth provider if I can generate a um a general ability right okay yeah this is a a collection um so it's not it's not like officially in our nginx talks or not like um it is it is like my my hecky my hacky notepad of of what and when to use and whatever so I use this Josie CLI tool it can be installed on Ubuntu or on Mac I believe with Brew um and what what that is is that you can you can easily with Joe's you can easily generate Json web Keys jwk which is another password In This Crowd um it is Jason Webb Keys which are basically the the breaded butter for for encryption and because we need keys for for all the encryption parts so the jwk part is I need a key and jwk is the representation of one or multiple keys in this in this special Json Json ice format so that's number one here in this document that we generate keys for a signature like like a normal normal Json web signature jws and a little bit later in this document so what you can see here is we generate keys for asymmetric cryptography for um like Json web encryption with with this Josie tool and it's a little it's a nice it's a nice walkthrough of how to how to create a like a keep here and when I'm talking about a key pair I mean private and public key again very important note here never share a private key with anybody else that's why it's called private key you can share the public key that's why it's called public key but never share the private key and in this example what we have right now here on screen I'm generating an encrypted encrypted Json web token I start with generating the keys like the asymmetric RSA key then I generate um any crypto token and and what you can see here this is example number one out of two where just use a randomized Json payload as a ciphertext so this now this example does not contain assigned Json well okay token as the cipher text this is example number one but when you scroll down a little bit in this this document um a little bit more there you go one liner jwe all right so oh yeah there we go so C is like Echo we say sub is test new name is whatever and then we pipe this to jws then we sign this signature yeah we sign it and make a jws out of it and then we use the signed Json web token as the ciphertext for encrypted Json web token gotcha and then so we're then passing this into into this encryption so we we've got a we've got I mean this is actually this this illustrates it really nicely here is my payload this is the important stuff this is what I want to communicate to the to the the end service some information in here that says I am who I am then I sign it so that I I know that the if I if I then run a Check sum against it against the checks on part of the um of the the whole token I can see it's been unaltered and then I'm passing it into this which is going to encrypt it to make sure that nobody else can poke around inside it okay so there's there's another example on that page for the down further down further down under this to do part I think okay no it's not but let's keep let's stay here for a while okay um this is config even I recognize this yeah that's the that's like the the nginx configuration on of like what we're doing as job directive is is the like the kickoff we tell Engineers hey this this location This Server is protected by a Json web token that we specify the type that is signed okay that is signed or encrypted or nested nested is the combination of sign and encryption I understand right and then we specify the the key file again bread and butter for for the encryption and the signature and that's basically it and the very very cool thing with the latest releases here this proxy pad header authorization better what we do is this job payload variable is automatically filled with the signed Json web token that was encrypted by jwe so that means all you have to do in this configuration is like tell nginx hey I haven't asked the token I want to decrypt it here in the jwk file are my keys keys okay then and then the next step I say look this is my this is my packet service and this service requires the bearer header and this is this better keyword is another another standard that came across with the Json Webb tokens it's RFC 60 6750 and what we do is like we build we get the payload which is assigned Json web token out of the encrypted one and paste it here in the better header and sending it along with the request to the backend and that's that's the whole Magic on the nginx site oh right so and that so that's um so just just for the for the the less familiar with with nginx I'm sure there's everyone here on this on this stream is is a complete expert but maybe I'm maybe I'm the lowest common denominator that I'm listening on a certain Port I'm setting up the fact that we have we are using a JWT auth the the auth type the location of the keys and then down here this is we're just we're going to pass this to the assuming it's assuming it's authorized I'm going to pass it to the back end and I'm able to extract the payload just with this pre-created variable that just magically appears once we've decrypted the token and this is the this is essentially the JW s the signed token that's going to get sent to the back end and I think I think I'm right did I read some of the the other even if I can actually extract the actual claims claims with a JWT underscore claim name so if I want just the username I can throw that into a different different header as well that's really cool so we have we have um special nginx variables and very cool feature here is we have on the nginx.org website um other documentation there is um a nice little link very important a list of all nginx directives in the list of all nginx variables and on my YouTube channel there is a docs nginx docs Master Class video and that explains exactly this because in here you see all the variables we have around in in on nginx so that means you can use this dollar jot underscore claim underscore and then any claim you have in your in your Json web token like user uh username email whatever you want to specify can be extracted or will be extracted by nginx automatically by this by this um by this technique or with this variable um that's that's actually really useful isn't it that all the all of the um all of the claims are populated already for you as separate separate variables so you don't have to you don't have to go and write any code to extract them you can just use them in wherever you want correct Okay so I think now I am I am almost at the point where I understand what's going on so just to just summarize what we've talked about today because we're getting kind of towards the top of the hour um and we've got we can rather than just me handing over my username and password to a third-party site who I may or may not trust sending them random bits of information and then having separate authorization wherever I go I can take advantage of uh some kind of authorization provider some authentication Service and that's that's I can use things like you know my Google ID or my Facebook ID I've seen all these like authenticate with whatever that means I get issued I authenticate and I get issued with a token that's been signed by them and when I present that to my my third party web service assuming that's configured to use or to trust the the uh you know the auth provider they can then ensure that I am who I say I am because it's been signed and inside that play inside that claims payload I can have additional information and then to protect that I can also encrypt that using symmetric or asymmetric keys and that creates like a nested token where I sign it sign my token for for kind of um validity and then encrypt it for obscurity if you like and then that gets that can be then decrypted and checked again and the nice thing is that nginx can do all of this in front of any other kind of like back-end servers and then hand that information back to them in any form it can either pass the past the whole token back after it's been validated or it can pass sections of the token um so we have and that's available I think if I wanted the the basic authentication with um JWT that's available in the R20 3 is that I think I've got that in there but if I want the nested capability I have to have the r25 which is the very latest and shiniest right so we have Jason Webb tokens got like introduced in um I believe r29 while r19 the latest jwe ones is r25 which adds the asymmetric cryptography RSA um to the to the jwe and yes I said uh we could spend we could spend uh at least two days of like talking about jwts jws and build build demos and ecosystems and and poke around with it and to be very honest this is the best way of learning it like play around with it the Josie tool I've just showed you in this gist yeah is it excellent is an excellent way to learn and to generate tokens and test without setting up an IDP like key cloak or um Google IDP or Azure whatever right yeah when I looked I couldn't I couldn't find many that were doing encrypted tokens um so I think I did have to resort to to using Josie or some some python code to make it work um so yeah being able to test it yourself being able to create your being able to be your own ID Authority is is useful it's good for development it's good for engineering because you can issue as many tokens if you want the Josie uh tool is is around for python as well um there is a python dependency called JW's JW crypto and the JW crypto one just includes um and I think this this is public as well um I believe so because I was able to get to it so um right so let me just share that so maybe we can put that on the screen for another minute it's not an it's another just small hacky implementation of the JW crypto um library in a python wrapper that will generate jwk and it gives you a sense of what you can what you can do and so and as I said I could talk at least two days about JWT jws jwe is even more complex because of the whole encryption part the whole ecosystem what is the signature what algorithm we can use for the signature um and to do the the signing part and all that stuff so what I'm interested in this is something you can leave it down in the comments on LinkedIn I think we're on Twitter we're on YouTube um if you're more interested in more generally what is or more technically what is all things about JW T and jws and encryption in an in a sense of how we can implement it right to not have security holds um in in our in our token chain like how to verify it how to create it and how what what information should be stored with the front and whatnot um I would really like to create more content about this bit as it is I love it I really like token based authentication I spent almost five years right now or more six years learning about all that and um I'm very happy to share all that knowledge I have if people are interested in so if you have any ideas any any thoughts or suggestions on what you want to see in which format is it a lab webinar live stream hecky whatever thing just put it down in the comments so I'm able to see it um so that would be that would be great if we can link on top of this one well I mean I I think I'm I think I understand I think maybe I could follow on with your next slab now I don't think I would have been able to do that with before this this session today so I I kind of hopefully we've got to the point where we've level set the understanding about tokens and authentication and what nginx can do with it so maybe the the next move is to to do some Labs or to have another live stream where you get even more technical we might need to get a smarter co-presenter for that one but um I think we are getting really to the point where we should uh we should sign off um thanks for putting the this the links in the in the chat uh Marco um thanks for the people that have left comments thanks for everyone that's watched thank you Timo for explaining this to me in simply enough for a a marketing person to understand um and hopefully we'll see you again all on another live stream sometime soon oh and if you want to try any of this out I should we should probably get the product pitching right at the end you can get a free trial of engine X Plus which is what you do need nginx plus to make some of the um to make the JWT capabilities work but you can get a free trial um it's pretty lightweight in terms of the the process to get get hold of this uh I think you'll find it really easy to do all the installation instructions are available as well it's really easy to get set up on any platform of your choice um and yeah that's I think all we need to say so thank you very much for for tuning in hopefully you've left this uh this live stream slightly more informed about the world of authentication and jwts jwes jots and jws's I hope I have and uh we'll see you again soon on our live stream thanks a lot bye-bye

Channel: NGINX

Views: 1,075

Keywords:

Id: ZYbML-Q7Mac

Length: 68min 27sec (4107 seconds)

Published: Wed Dec 08 2021