[Music] so I'm David Blevins and I work in a company Tomi tribe we do a lot of stuff around middleware and so a couple years ago we you know we were one of the creators of Apache Tommy we do a lot of support for that stuff and help years ago customer a says hey you know we rolled this stuff out now what what are we going to do secure this stuff and we're like okay well basic off of course that's not going to fly and so we did a lot of research and to try and figure out how to get up to speed it was kind of interesting story you know having participated in to the standards for a really long time I don't just read the specs because I know there's like usually story behind the standards so you know one of the things I did to try and get up to speed was look at the names of the people who are on the spec look at the names who are on there now see who left contact them say what do you think about the spec why'd you leave and they can't wait to rant and so you learn a lot of stuff really quickly but one of the things that I really had a problem with trying to choke down this whole world was how completely complicated it is almost like intentionally designed to deceive you because there's so many choices in specs and I think this quote really really really summarizes the problem of security these days which is is a nice thing about standards are so many to choose from and so kind of after going through this process of learning I really wanted to put together a talk to try and bring a simple perspective of it because I think that you really don't find simplistic talks about security for some reason you either get people who are super really into the details and can't really describe it at a high level or people who are too afraid to talk about it so I decided I wouldn't be too afraid to talk about it and I should come out and you know describe it anyway so you know one of the things that's tricky and standards is well they're always like no matter what the topic is like 200 pages or a hundred pages even though maybe there's not much there we always rename everything that already existed so you know I guess if you're paid to write a spec you know you're paid by the page apparently and so you know it's a it's an interesting thing another thing that's proud thats kind of tricky with standards --is security-related specifically is every one you read you feel like you know less because it mentions some other spec that's an extension or an addition or light to that one so you go reading that when you go wait a minute go over the end what am I to be finished you know and so it's it's you know so in this talk we're basically going to try to show uh you know how rest security is done at a high level in the most common practices architectural II and you know what that means in terms of how you roll out a system so we are going to show actual HTTP messages and things like that but really we're going to we're going to start with you know an architectural perspective so we're going to cover kind of three styles of security that are out there of course we're going to do a recap to so in a kind of like a baseline what what what our security looks like with OAuth excuse me with basic auth as a baseline we're going to morph that into oo auth to using regular tokens see how that looks with JSON web tokens and what that does to our architecture and then we're going to kind of go tune to an interesting style of security that's new called HTTP signatures which is I like to describe as the Amazon style so we actually got that recommendation from them the the client library for ec2 all the AWS clients are written in Java even the command line one and so we wouldn't found the source code and said what's up what they were doing for security they use a concept called signing you know message signing and we asked him hey qui use it and they're like well there's actually a much simpler draft out there so we're going to go into that and there's actually kind of some compelling reasons to use them both so before we get into it you know so who's who using security now so whose basic off right let's let's do this let's go basic off and it's okay all right so we got a couple hand who's using OAuth all right that's pretty good for those of you using OAuth who is using OAuth with JSON web tokens fewer hands so that's good I mean not good but I mean you're here so that's good and then so we didn't quite get all the hands yet so some other forms korva security I don't know well you know who's you who has no users okay and then I guess who doesn't secure your apps so some of you didn't raise your hand so I guess what would be your your your someone list out something that wasn't mentioned okay well you are using signatures do you work for Amazon okay that's it's awesome okay so in our baseline architecture so we can actually compare these things and how they actually behave in terms of amount of traffic we're going to have a baseline type of architecture we're going to have a thousand users generating three TPS each they're extremely aggressive users and so we're going to assume that we have a microservice architecture in the background all right there and so we're going to say it takes four hops to satisfy the call before we answer can get back to you to the user so we're going to have effectively 3,000 TPS in total flying at the front door and on the back side that's going to result in 15 12,000 TPS so that's our baseline architecture this is with no security that's just playing up straight traffic okay and so if we take a look at what basic auth looks like in that and so here's just a quick recap of basic auth it's extremely secure because we have fancy username and password concatenated together using extremely complicated algorithm called base64 which nobody knows about only the highest quality programmers and so of course we're passing everything username and password ever requests but that's not the worst of it architectural II if you want to do you know a check at the beginning of every request now we're having basically three thousand TPS happening against our LDAP server or wherever storing those username and passwords we have that amount of traffic so it comes in and for everyone we have another three thousand other transit another request going down so effectively have three thousand TPS going against LDAP typically people are not using authentication in the back who who secures traffic once it enters your enterprise ok three hands that's the common case it shouldn't be because of course no one's ever heard of contractors we don't let anybody in our front in our in our in our corporate headquarters that we don't possibly know in fact you know target is anybody from Target good ok so target one of the issues that got them severely hacked was of course people who were contractors it wasn't the front door it was people who they let in you know the front door of the actual headquarters not the front door of the internet and so you have to actually secure the traffic on the back end which is kind of one of the things that we should all start moving towards so theoretically if you do that and you try to lock things down to username and password again on the back end of the side now you have 15,000 transactions per second going against LDAP which totally does not scale so what a lot of people do is whitelisting who's using a white listing that's much more common well one person I see a lot of whitelisting it also has some limitations in the sense that white listening is a natural enemy of elasticity if you have something that fires up a whole bunch of JVMs they all getting to get brand new IPs and if you bring them down bring them back up again you're just going to be continuously getting new IPs and so whitelisting is just does not work with elasticity okay there's another problem with basic off or not securing the back end if you don't secure the back end you're writing architectures that basically work like this micro-service a makes a call over to micro-service b and says hey get me all of Joe's salary information and of course micro service B says yeah sure here it is no proof no authentication just because you're there your trusted and you give away everything to everybody and this is not exactly the best way to be done to be designing applications but is unfortunately what we're doing with these days so basic auth and its lack of scalability its lack of security is affecting our architectures and many awful terrible ways so of course now we have a hack comes in and instead of now let's say we have the evil people from the awesome you know country Latveria which is which is a very real country if you live in the Marvel Universe they come and decide to hack you on the front door and you know now they're generating 6000 TPS in bad hacking traffic so now we have 9,000 TPS in addition you know going against our our LDAP system and so this is just really really bad so Oh off to is of is what is being sold as the solution to basic auth and passwords so the theory behind it is effectively that what we're going to do is give each mobile of ice a token and on that mobile if you've got to a one user and they have three devices effectively there's three sets of credentials so you would log in with your username and password you would get back a token and each device will have its own token its own user name and password and the theoretical advantage of this is that if someone loses a device you can remove the username and password effectively the token for that device and that's great you can do that for all the ones that people lose and overall they don't lose access to all their stuff just the one that was lost that's some of the theory that drives so off - into existence there's a process of granting and getting those tokens they call that a grant process it's very very fancy what you do is you post your username and password to an end point where you get back a token see that on the bottom an access token and a refresh token to have an expiration on them and when they wear out you've got to re-up the whole both tokens so so far we're doing some incredibly new inventions because never before have you used form URL encoded to send a username and password in a post body to a server to get back a security token I mean this is basically the same thing we've been doing for the last 15 years but now this is but but trust me this is all new because if I'm a you know writing the specs you know I got to like make my paycheck so I have to rename everything to make it sound like I've invented something ever noticed like if you've been in industry for a long time 90% of what's being portrayed as new is the same and 10% is actually new but they've renamed the previous 90% it's pretty much what's going on here so once you get that access token so you send it in your request via the header authorization and instead of using basic as the scheme you use Bearer and you take that same access token and you send it over and over and over again till BAM it eventually wears out and then now you have to do something called a refresh which is you take that second token that you are given and then you post it to the server and you get back a new access token refresh token pair so this is what is at the core this is the basic thing so in this refresh process we have exchanged our old access token refresh token for a new access token refresh token so effect if you want to think of them as one is a you know fast lane traffic token you send it all the time until it wears out you use the Refresh token to get another access token refresh token pair once you have that new token you can go ahead and send it just like you were the other one and then that's how the basic concept of Olaf 2 works so what have we achieved we have a lot more passwords because those access tokens if so if you see them on the wire and you take them effectively you can be that person and so this is the this is the kind of funny thing about about these kind of standards in the sense that if you were to imagine bringing a vendor in and you're telling them you know we have this password based system and we really want to get rid of that move away from that and the vendor says I got the greatest solution for you it's called tokens what are tokens there's strings what are these strings their unique strings that you use to log in so like password no I don't think you're listening to me they're called access tokens and it's sort of like okay you know but if they come in through a tit and say oh we're going to sell you the solution for passwords is a lot more passwords of course you'd kick them straight out the door so it's sort of like this weird thing where we can't just call a spade a spade and it's it's a it's ironic so you know the another funny thing is grant a lot to spec calls the whole process of logging in the grant process and describe a couple different ways you can get a grant but of course it's just logging in and in fact they haven't even changed the way the HTTP message looks when you post your credentials there to log in there is an additional credential called grant type that's usually set to password and but other than that your form URL login on your website looks pretty much the same way it does it ought to but of course it's not called logging and it's called grants right because you know if I'm writing in a spec you know I get paid by the page and so therefore I have to make a whole lot of description I mean you could be like by the time you even get through the grant section of the oauth2 spec you're like 30 pages in and then never call it logging in they call exchanging credentials for tokens and blah blah blah it's it's quite maddening what would be a better word for token I don't know slightly less crappy password if we were to be honest about it right it's it's very stealable or I like to call an equally crappy HTTP session ID because basically that's what we achieved right so we posted our user name and password and we got back a token which is a string about yay long that identifies us in a system so how is that different than an HTTP session well if you ask the security expert who wrote the spec I don't think you're listening to me I said it's not called the session ID it's called a token and you know it's like okay so we've so far I've just been sold HTTP session IDs with form URL login absolutely no different so this is the way most most oo auth two implementations have been written for the first five years of the oauth2 spec and so what happens with this architecture is that now instead of having three thousand transactions per second go against Roth we're first logging in we're posting our using a password to the top so I've moved the LDAP server to the top let's say that everybody has to log in with a username and password out of form once daily okay so that's 1,000 transactions that are happening over SSL to the LDAP server just as before now we're issuing these tokens we're putting them in a store which is now at the bottom and now we're doing 3,000 TPS against that so architectural II we've gone from 3,000 TPS against an LDAP server to 3,000 TPS against our token server did we really gain anything or do we just add more points of failure it's sort of a lateral move from that perspective also if you have a system where you're trying to pass security credentials in the back let's let's evaluate how OAuth 2 with just these short access tokens looks when we're trying to lock down our back-end so well we'll have one service call over to service B over there and give the little access token and say hey can you give me a you know we'll Joe salary formation another service says who the heck is this they say I have no idea who that is so of course you got to make a trip to this - the token server again so now we're doing there are 1,000 transactions per second against the token server to figure out who's on the other side of these little tokens and of course now our token server promptly stopped you know step starts on fire because it's processing basically 55% of all the transactions in the entire enterprise becoming a huge bottleneck of you know point of failure and then it promptly dies and now we're getting no transactions per second so effectively we've taken a you know exchanged one type of bottleneck for another that is an HTTP session ID server no doubt about it so these access tokens effectively being pointers to state in the backend maybe we can think of some better names for access tokens how about access pointer or access primary key might be more on the nose and more honest for what they actually do but of course we're not going to call them that because then people might not like them so we keep them called tokens which by the way token is just some random word for string they could have used string but no token sounds way more official so it's it's a you know I have a very low tolerance another word for oauth2 might be high frequency password exchange algorithm I that's my preferred favorite I think that much more accurately describes the whole system so you know we haven't achieved much other than exchanging a lot more passwords a lot more frequently because if you see any of these things on the wire you can pick them up and you can gain access to those systems so there they're just as vulnerable as a password the only hope is that you exchange them more quickly but the problem with standards is everything's optional so you know after you've read the 100 page of the OAuth 2 spec you realize refresh tokens are totally optional and the policy around them is totally optional so whether they're supported or not is not even a guarantee and so if there is no refresh token process then effectively your access token lasts as long as a password because you have no way to get another one other than for the user to log in again and so we're stepping further back from progress and it's it's not great so enter JSON web tokens so JSON web tokens are a way you know of course the greatest thing about the JSON web token spec is that they like to think that they're way bigger than oo often can solve world hunger and so when you read that spec they're not going to talk too significantly about OAuth and they're really going to talk to you about the very big problems that they solve in the world but meanwhile from where we're sitting we just need to solve this problem of that access token being pretty much crap and so JSON web tokens are a concept where you're effectively taking a JSON map of user data your base 64 encoding it you're signing it with a public or private key or a symmetric key and then you're giving that to the user instead of that short little access token so inside that thing there's expiration times there's information about the user and all sorts of great stuff so what we had previously was effectively this as our access token and when you use a JSON web token instead of that you end up with a much bigger looking token now that looks awful but bear with me for a moment we've actually achieved some amazing things just with that short change ok so effectively what that token is is three parts the first part is that what's called a header the second part is the actual data and the third part is the signature or more like this and here what here is the slide that tells you what it actually looks like so we have effectively two json maps and a digital signature so the first json map describes how we effectively signed and encoded the middle part and the middle part is the magical thing that describes the user the easy way to describe this that's a cookie and effectively I'd like to describe it as a signed cookie and so here we say oh the username is Snoopy we can have other information about Snoopy we have scopes which effectively can define you know what permissions or roles Snoopy has and then of course there's expiration and what time the token was issued and that helps us to get much more controlled description of when these things expire and and how long they should live and then the bottom part is going to be the actual base64 encoded bytes that of the of the first two so effectively what we do is to make the blue part we take the purple part and the yellow part and we digitally sign that then we encode the bytes and we make that the blue part at the end we tack all three of those together we send that back to the user so there's a very subtle change that's why I like to show the architecture because if you just show this versus the Elva one you're going to go well I would probably want the shorter one but there's a very huge impact to just that okay so what we had was effectively this we were posting our username and password to our LDAP system we were scooping out user information we were generating an access token which is effectively a pointer we're inserting that token plus user information into now our token store this was the previous way and then we pass our pointer back and then the client holds a pointer and the server side holds the State that's what we had what we can do now with the JSON web token is effectively subtly different we first do the same login process we check their information against our LDAP store or whatever identity store is we do a scoop of information about that user we format that as a JSON map we sign that that JSON map we insert a pointer into a DB for reeve occasion purposes only and then we send that full map back to the user and the users now holding their state and so now we've flipped it around instead of the state being on the server side and the pointer being on the client side we now have a pointer on the server side and the state on the client side so what that means is if you have six million mobile users each one of them is holding our own information on their phone and they send it ever requests and you do not have to have six million records of state in the back end describing each user in detail very subtle but high impactful change it's the difference between an HTTP session ID and an HTTP cookie it's very very significant so now let's take a look at how this plays out in terms of architecture if everybody has their tokens on their mobile device so we have the same login process or excuse me I'm sorry I'm not doing justice grant process I'm going to I'm definitely not going to get it get a job as a spec author for for oauth2 or anything anytime soon we're doing our login process and we're posting our username and password and then we're getting back our same access token except now it's much bigger than before and the refresh token is going to be very similar it's going to be this also if your system supports refresh tokens which I advise you to ask that question if you have an oauth2 system that you're using now and they don't support refresh tokens you should ask them what if they do or not some systems that I've that I've seen use the same refresh token over and over and over again the stronger policy is that they should be single-use you use the Refresh token you get a new access token refreshed I'll compare the old one can't be used anymore that's the stronger policy because that Refresh token effectively if it's not ever expired you could just log in a whole bunch of times with that and if someone steals it it's the almost worse than password okay so we get our now are much bigger access token back so now we're instead of sending that smaller one we're sending our JWT or our jot and we send that ever request and now here's where the impacts are more visible so just as before we're going to say we're logging in with using them and password once a day so our 1000 users are going to trigger 1000 requests per day to our LDAP system then they're all going to get back access tokens which are JSON web tokens that has their information in there it is the most sane thing for them to be public/private key signed I'll go into that later but some gateways just do symmetric signatures there is a subtle difference as with it as well there but effectively what we're going to have is 3000 tokens per second being sent because we have 3,000 transactions per second being sent each of them is going to have an access token in it a jot and we're effectively able to check those using either the symmetric key that was used to sign the token in the first place or the public key corresponding to the private key right so who's who's familiar with just basic encryption in terms of symmetric versus asymmetric okay excellent there was some hands that didn't go up and so effectively the difference between you know a hash is if you know a signature is best described as a hash that's encrypted I mean that's a cheap way of saying it and some people will get up in arms and saying that's an oversimplification of the process but hashing is effectively the act of taking a number and you mutate it as you see the day to go by so effectively imagine you have a stream of data if you can stream a file through and you got a snowglobe and you just shake it up and you keep shaking and when the data stops moving you stop shaking and whatever that number is that's the hash and it's statistically unique and so if you change one byte theoretically the hash should come out different differently and then so to protect that with identity you're adding some sort of encryption so that you can prove that you know whoever made that hash is the one who who's authorized to do so so we're able to check that that JSON web token using the public key that's there on Gateway so with a single signature check we can verify that token to be valid or invalid we don't have to do any hits on a persistent store and so effectively instead of having the 3,000 TPS against our stateful Olaf - token store we now have to do a check basically once per refresh and that's a policy that that's common so you know we have a system that that does this we check a store on the refresh to see if we should allow that user to get another access token refresh token pair for the purposes of maybe they lost their device maybe their computer was hacked and so we will find their tokens and we be in the Refresh tokens that are stored and we wipe them out and so effectively if you only check your store for identity you know for a for reeve occasion in the in the event which is rare that you need to actually aggressively lock a user out if you do that like once an hour then effectively you wind up with 55 you know 0.55 TPS going against that refresh token store the excellent thing about this is if you have this public-private key scenario set up the Gateway holds the private key and is the only one that can basically create tokens you give the public key to all of the services in the backend and they can also verify tokens the value of that is that you can start to propagate identity from front to back in a very cheap and effective manner so we're going to add in signature checking JDBC checking in the backend and we're not adding any hops to that middle server there in the bottom so we're not going to have the 15,000 TPS going against the center store and we're going to get security in the backend for the cost of point five five TPS it's a very significant change and so now we have a world where effectively when that micro service says to this micro-service can I have Joe's payment information unless this micro service here passes the JWT token of Joe over to that micro service that micro service should say no way you're not going to get Joe's payment information unless you have Joe's access token so the right way would be for that access token to be passed from micro service to micro service which means you and your app code are taking it from the incoming HTTP message and you're putting it into your outgoing HTTP messages to your other micro services and that's how it propagates through the enterprise and provided you take the public key of the Gateway and you install it or give it to all of the you know the docker images and put it all in the images of all your various micro services they can check that access token for being you know forged or not with simply a public key check they don't need to handle the revocation or any just fancy stuff because you can just let the Gateway do that but at least no one can forge identity in the backend of the enterprise and so now when micro service a says to micro service be give me all of Joe's salary information and passes Joe's token micro service B should say you got it here it is and now we have a very strong way to propagate identity from the front to the back of the enterprise very cheaply without any hops to a centre server so we've achieved effectively stateless rest security and so you know the funny thing is is that when you know when we talk about our architectures of developers you know we always Pat ourselves in the back and go oh we wrote a stateless architecture and then what do you use for security adds something and then you know well we go and write these beautiful stateless architectures and then the security team comes and slaps on a stateful security system and ruins the whole thing but we don't really think about it because it happens at the end of the project and so therefore you know we we still walk around patting ourselves up in the backbone we have a totally stateless architecture yeah except for the fact that you're doing all of your quests are hitting your stateful security system so there are some benefits to this aside from just the fact that we can propagate state from front to back now let's have very a come back again and try and hack us one more time so they're sending 6000 TPS in invalid tokens at the front door and normally if we're doing a stateful system we would have to go to to some token store and check to see if those tokens are valid or not so that evil country of Latveria is triggering 6000 TPS to our central point of failure which is not a good thing but with the JSON web token we can check those tokens that Latveria sending to see if we made them by doing a simple signature verification if the signature doesn't verify we drop the token on the ground we don't do anything else after that so what effectively means is that evil traffic can be stopped at the front door by a simple asymmetric or symmetric signature check that can happen in memory and the key of the Gateway you're not going to have a thousand of them you're going to have one and so you can hold that thing in memory you can horizontally scale that extremely easily and you can effectively block out all that bad traffic with no hits to a store so effectively the only time you're ever going to do any refresh check or any checks on a store is for valid traffic it's for honest traffic so effectively honest traffic is not affected by evil traffic whereas if you have a stateful security system where those tokens are being checked against the store evil traffic and good traffic hit the same spot an evil traffic can affect good traffic but if you use this simple technique where you're signing those tokens you can check with just in memory really quickly that those tokens are valid or not and stop them cold right at the front gate so just as before we were having 3,000 transactions per second going through straight through the gateway very little chip very little work and then we have our work on the backend checking those tokens but that additional 6,000 TPS has absolutely no impact on our back-end or on our store and it's dropped cold at the gate a great application you can use to try and verify these tokens and use you know to make tokens and we'll work with them in your testing code is the Nimbus library so I would recommend you know grabbing a grabbing a snapshot of that it's pretty much the most popular one out there for for composing the various kinds of JWT tokens okay so that describes the OAuth perspective of the world which is very fantastic for kind of mobile usage where you have a user on the other side and they're logging in you you're creating this thing it describes the user but when we were doing our research you know we came across the Amazon approach and in there doing you know a couple billion dollars of business not using OAuth so it was very curious to us what exactly that's all about so they use this concept called message signing so they're taking and employing the same concept of digital signatures but what they're doing is they're having you sign your actual HTTP message and so they do in a very complicated fashion they sign like three different things and then they sign the signatures and then it's all really SuperDuper you know crazy layer on top of layer but what they recommended to us was to go check out this other spec called HTTP signatures which is in draft form and it's actually I don't know how it's going to actually graduate because it's like only 20 pages so they need to add at least 80 pages to that thing in order for it to finally become a official standard I think so it's too simple it needs to be ruined and so you read it and it's dead simple you can understand it in a day and I apologize in advance for its lack of a sexy techno babble so effectively how it works is you have all of your headers and all the stuff there you make a signing string which basically means you make a piece of data that you're going to hash and sign just like the JWT token is hashed and sign that map is hashed and sign instead of signing that map which this which the Gateway does you as the caller you as the client you sign your headers so you take the headers of your outgoing HTTP message you can catenate them together in a big long line separated by new lines and then you hash then you use your symmetric key to sign that you take the base64 encoded version of that signature you put it in the header of the authorisation along with the name of the key you used and the list of headers that you signed you're allowed to sign any headers that you want you don't have to sign all the headers if you don't want to per recommendation of the HTTP signature spec you should sign at least the date header can anyone guess why replay attacks exactly and you cheated because you're doing this already but I like it anyway so it's not cheating to know things so you know so effectively unless you have some part of data that changes the hash is going to come out the same and if the hash comes out the same the signature is going to come up the same and if you're sending the same signature over and over and over again then someone can just see that on the wire pick it up put it in their message and send it off as and pretend to be you so you have to have something in the message that changes so that signature won't be valid if they someone tries to reuse it and I'll show you exactly kind of you know how signing really is the secret sauce to all of this security so to kill close up of it we simply have these four parts that we including the authorization header the name of the key the algorithm the headers the signature so how this would map to like Amazon for example is when you create an account with Amazon ec2 you get access token key ID and an access token and you know any time you use their client library anything you have to give those two bits of information to the client library what they're doing with that is they're using the key value to sign the outgoing message they're putting the key name in the actual message and they're sending it off on the receiving side Amazon is taking the message that they got they're making the same signing string using the same format and same rules based upon the data they see in the incoming HTTP message they look up what your key value should be then they hash that thing and they sign it with the key they think you have and if the bytes come out the same aka those base 64 bytes if they come out the same you're allowed in if they don't come out the same a few things could have happened one you lied you're not who you say you are two you are who you say you are but someone tampered with your HTTP message and change the value of one of your headers or change the value of the body and then now your message doesn't verify either way you don't want that and so Amazon doesn't let you in if any of those things happen the difference between this and the JWT thing is the signature on a JSON web token is around the user data not around the HTTP message the signature around a HTTP message signing thing is the message itself the two of them actually fit very well together I'll go into that in a moment but there is an issue with this approach and the sense that it's great because there are no secrets sent on the wire so this is the good part no secrets sent on the wire you don't have to use as a SSL if you don't want to and effectively we're sending no secrets of any kind no passwords no tokens nothing that can be simply observed and stolen right because effectively what you're taking is that your your Amazon key never leaves your pocket you know it's a nice way to think about it is if you're taking your HTTP message you're putting it an envelope you're putting some wax on there and you're taking that thing there stamping it and you're sending it off you never send a Stamper you just send a reflection of the Stamper and so there's nothing for people to steal that signature is only valid for that one message because you're changing data like the date header and so on and so therefore there's going to be a new signature on your next message and a new signature on the message after that and so if they worry if they want to hack your account they're going to have to figure out how to reverse engineer your your key from the observing many many signatures and it's not exactly an easy thing to do it certainly is a lot harder than just looking at your password or looking at your access token even if that access token is a JSON web token if you see it on the wire you can be that person and so that's the nice thing about this approach is that nothing that is needs to be protected is on the actual wire if someone observes 100 percent of that message they can't be you so it does bring back the problem of there is no way to communicate the users identity from all the way over here to all the way over there because if we have four hops at each individual part of our of our back-end we need to sign each of those individual messages separately because the call that microservice a makes to be which makes to see which makes 2d is going to be a different HTTP message the resulting signature is going to be different unless you have the users key on all those systems which you wouldn't then you are effectively only identifying server a to server B and server B identifies itself to see and nothing represents the user so it does put back the issue of one server effectively saying just because you can talk to me I should let you have everyone's information so that's why if you combine Roth 2 and signatures you take what are effectively orthogonal concerns and you mix them together to have a best-of-breed architecture so you still have users log in via OAuth 2 at the gateways so you can get a token which can be put in any HTTP message and sent through your back-end ok but then to prevent your back-end from being a little too open you still implement signatures from each individual point in the network and the reason you would do that is because let's say you know reality is is you don't have one team who supplies all your micro services you have several different teams apply several different parts of your architecture maybe you've got one team that has all the personal identifying information for people who are your users and there may have an endpoint that exposes that information and if you simply add the policy that anybody who has an access token of users should get that you might open yourself up to some vulnerabilities still in your enterprise say you've got team B over here and they're responsible for inventory of stores but they and they get some that person's token because they're any we're in a call chain right there's an app that does all sorts of things on behalf of the user and they see that the token at some point and they decide to go over to the to the personal identifying information endpoint and say hey give me all Joe seller information they would still get it especially if like I say especially if that token becomes like a very high-value piece of credential and gets sent around through the backend so what you do instead is you issue a symmetric key that is required to be in possession of the servers who need to call that rest service so that rest service effectively can only be talked to by other teams in the enterprise who have the corresponding symmetric key you don't need to make a symmetric key per service but you can make them per you know app or whatever kind of domain you want to make and define you effectively generate and as an assign a symmetric key to that service you hand that out to only the people and only the systems who should be allowed to talk to you you combine that with the OAuth token and now you have the system's identifying themselves to you and these systems over here can't talk to you neither can these systems and you have a mechanism to identify the user traveling through the enterprise and effectively we've achieved Nirvana of you know security in our back-end and it's all done in a stateless way because we can hold these symmetric keys in our docker image right next to the public key of the token server and we got two credentials and we're able to verify everything that comes our way without a trip outside the server so effectively signatures is driving all of modern rest security these days so if we do this now we have a mechanism where we can still pass that security credentials all the way from the front to the back and each hop is also identifying itself to the server next to it in terms of you know saying whether or not it should or shouldn't be able to to talk to that server so you know in the previous way if we were to do the OAuth 2 we would still have you know security credentials being sent so we still have the user logging in this should not say passwords it should say tokens have to update the slide so effectively with this hybrid approach we're doing heavily OAuth 2 at the front gate and then we're doing heavily signatures in the back end still propagating those two tokens so the observations here are that you know at a high level the commonality between all these techniques is that digital signing digital signatures is driving security in the modern day for rest and if you understand that concept you can get quite far in and simplifying the world and so you know the plain Olof to approach the best way to think of that is that's an HTTP session ID okay so you have that pointer to the back-end state and but it's effectively a stateful architecture so all off - with a JSON web token is assigned cookie it's a stateless architecture so the fact that they're both called OAuth 2 is almost like painfully misleading because one is a session ID and one the cooking and so you know if you you know what I would recommend everyone to do is go out and get yourself familiar with the concept of digital signature because that is really the underlying you know secret sauce to all the stuff going on on here so I hope you enjoyed the presentation I know all the sessions are going 10 minutes late so I apologize to the next speaker I started 10 minutes late and I think it's going to probably cascade out but thank you all so much I appreciate the the time and I hope you enjoy the session you [Music]
