OAuth and OpenID Connect for Microservices

all right yes my name is Jacque Badescu and I work at tuba technologies with identity solutions and identity questions all day long so I'm going to continue what David talked about here and and try to apply some of these concepts to real world problems and the real world problem that I chose was micro services and we've had some talks about that already which was more than I anticipated but I'll give you sort of a quick dive into what that is before I sort of dig into the the standards instead perhaps some of you missed the morning talk who knows so you have a traditional service anyway we have a bunch of components in our services we want to build these components we we add them together and then reform working system that deploys and that is our complete solution or our service that we deploy this is the traditional way of building most any software that we have today with it comes it's ordinary problems you have to build each component you want to update a component that you have to rebuild the entire system you want to redeploy a component you have to redeploy the entire system downtime maintenance times version control cycles all of these things are tied together when we work with these traditional systems built out of components but still delivered as a monolithic system scalability is pretty easy we just take a bunch of them and we deploy them next to each other the more we need but it doesn't really help us anything if it's one particular component that we need to scale more than others we need to just redeploy the entire or continuously deploy the entire system now as it turns out we started to build systems differently than this obviously as in software it's not a new thing it's been done over and over and over again but now for the restful word we start to build micro services instead and micro services then obviously if we take one of these component we deploy it independently of all other components and let it live its own life and that means we can deploy many of them next to each other we can we can run these systems to form a full service for us and but we're not no longer dependent on deploying the whole thing at once we can recompile the component we can redeploy a component without taking down the entire service and this is fairly interesting I'm guessing since we've had many talks on this already and scaling of course becomes vastly easier we can take the yellow component that we can deploy it as many times as we want on as many services we want and then we have scaled our solution to meet the demands it turned out to have which can be hard to predict before so what's the problem typically in a micro service or in a traditional service we secure it or we need to find out who is the caller what can the caller do and how do we propagate that information and that's usually done by providing some component in the beginning of the request chain or somewhere early on that populates the session object or the request object or whatever we use and pass it it on further into the components that are being called during the request usually this also means that we need to pick up extra data belonging to that particular user and we do that either directly in the beginning or we let the components do that but they share the state that comes in and they share this information and they share the access to the user repository in this this example so for a micro service that would mean that we would put all of each each of these components would have its own request handler then that would also have to deal with the identity coming in it would have to call the particular user positively to find the the information that it would need to populate its object and then handle the requests and go back response but if you change these obviously they then you have a lot of the same thing going on so you to have different paths depending on where it came from who called it where what information do you need all of these things so it's not really a fantastic solution when it comes to micro services to scale it like that so before we dive into what I think we should do I want to step back and talk a bit about OAuth I'm going to do it a bit more more more in-depth but not every arrow in the diagram but as David said and this cannot be pointed out enough is that OAuth is not for authentication not for authorization it's a complete delegation protocol and it's extremely scalable when it comes to delegation so delegation is I delegate access to someone to do something for me and that's what it is so that means that the one who provides the data can still refuse this they could still say no I don't want to give you this data because I don't trust you but the user has said yeah you can get the data so there's there's that's the different sort of between the authorization and the delegation and we should probably go into that at some other talk so Olaf has four actors we have the resource owner you the user we have the client the app typically for in the mobile world and the app back-end in some cases we have the authorization server which is the OVA server and we have the resource server which is where stuff is stored or stuff is available the service that we want to use so let's say that this resource server is a mail server Gmail or some other mail server and some smart dude wrote an app that has a sorts my emails differently or lets me know that some email needs urgent attention or something like that so my app needs access to my email account on my email server and I need to make that happen so the first thing that happens is that the client requests access the app requests access to the resource server by calling the authorization server the authorization server says sure you can have access if the 10 tickets so the use the authorization server will then redirect and let the user authenticate typically this is done this can be done in various ways but typically this is done by by showing a browser with the address of the authorization server in it so that the user is not really signing into the app its signing into the authorization server and when that's done the authorization server will will validate the credentials obviously and provide a token and this is called an access token this token is not something that the client can understand it's just a string of characters that it can use to call the resource server instead so instead of providing the users credentials down to the resource server it now only provides the access token to the resource server the resource server that needs to know is this a valid token so it calls the authorization server perhaps this can be done in various ways and the realisation services yeah that's a valid token it expires in five minutes and it belongs to this particular user etc and with that the resource server starts providing the data requested that's a simplified OAuth flow there's a couple more errors in there but in essence that's what happens when you when you use oauth2 so one really interesting thing and one very important thing about this is that the client the app doesn't know anything about the user at this stage it knows of course by looking at the data that it received from the resource server but that's that's not really a trustworthy source so all it had was some sort of a peg token that it sent on to the resource server and this is usually nice but in some cases it's pretty useless because what if you're you're more than an app and you have a back-end and you need to create sessions and do more about this about the user that just logged in and that's where Open ID Connect comes in simplified so we have the same image we have the resource owner but the client we now split it so we have an app on the phone and we have a back-end called my mail calm so we want to do more than just alert stuff about your inbox we maybe want to translate the emails and store them translated for you in I don't know some some fancy service so that means that our server here now needs to access the emails over there but it also probably needs to create a session between the the client app and the client back end and that session probably adds even more information about you because the result of your data is something new so it needs to know who you are but still we don't want to own all the identities so we start again the client wants to contact the resource server but it starts by sending a request to the authorization server the the user is challenged and provides its credentials same as before the authorization services yes that's fine and now it responds with the access token and the ID token and this is what's different so the ID token is an token that contains information about the user so they are used for different purposes the ID token says stuff like yes this user has authenticated yes this user's name is Jane Doe yes this user has an email of this and that and it also can add a custom amount of claims in there and and what the resource server then does it uses this ID token to create its own session and then it passes the access token on to the resource server on the request further on so the ID token is not really sent away it's just used for knowing stuff about the user and not having to build your own authentication service and have the users create passwords and stuff in your service which is useless because they're anyway going to use the other service and of course the resource server responds and all the data comes and the sessions are set up and everything is peachy so what was interesting about that the most interesting part that ID tokens gave us now was trust they increase the trust between the authorization server or the the party who issues tokens and the party who realized on the tokens the client this trust is now manifested by the ID token and the ID token is what what David also mentioned earlier a JSON web token or a jot and a JSON web token is a JSON document or actually many JSON documents punched the pilot compiled together encoded and then signed and it sort of looks like this you have a header you have a body both of them are JSON and then you take a certificate or a public key and you compile you sign this document and get a signature that looks like this that you append to the to the message and that's your your jot the signature plus the encoded data so it's not necessarily encrypted means you could you could easily read it but what's interesting is that all your clients now they can take the public part of this I probably said public comment you sign it with the private obviously you take the public part of this and then you validate the signature and you know okay the a s actually did sign this and did issue this authentication session I can trust that I can now create my own sessions on this I know that the user has authenticated that's really interesting because dots can also be used for access tokens so we know what even if we don't use Open ID Connect we can use dots for a lot of things and it's really like this there are two types of tokens we have a by value token and we have a by reference token and there's probably more but these are the two main types that we use a by reference token is a token that is pretty much like a C++ pointer it's a string the points space somewhere where information is located so it means nothing to the user outside the a s or the one who stored this information it's random you cannot decode it you cannot decrypt it you cannot brute-force it it's very hard to do anything with so it's completely opaque and this is the standard format of an access token the AES on the other hand it can keep a lot of information tied to this it can say yeah it was this user at that time with these claims that can do these things and it expires at that time that means that these tokens are fairly safe to send outside your network very good good match when you're on the internet and want to have a mobile client use your access tokens to to gain access to your your data on the other hand we have the by value tokens and yeah you know what that means now that's a jot typically it contains all the necessary information or most of the necessary information that we want so we take all the information we compile it down we sign it and we stick it into the message and use that as an access token and that is of course great because you don't have to call someone to figure out what it what this token is it's not so great because anyone can read it and even if you encrypt it you sort of expose yourself to two attempts of decrypting this or cracking cracking your codes so you don't necessarily want to share this around the internet too much except between perhaps trusted parties or sort of trusted parties so what we do usually do then is that we we split these tokens so we split the way we use it we say that we have an external world and we have an internal world so our reference tokens are issued by the authorization server they are then fired away and left with the client the client sends them back now when it's time to call an API then we have someone in the middle who takes this access token looks it up with the AES and oh yeah this it's it's this guy and the a s responds with a dot instead of just saying valid so it responds with the jot and the jot is then passed further on in the network so we essentially create a token translation point and it's it's not really more than that it can be a full-fledged API firewall but it could also be just a reverse proxy or some step on the way in your network but typically on the edge and it can cache these things it doesn't have to be stateful at all more than that and and that's it so let's go back to micro services now then so we had two initial problems we have to identify the user and we had to create sessions more or less so first obviously what I'm trying to get at is leave the authentication and identification to the OAuth and OpenID connect server don't bother with it your micro services all they do is provide access given that somebody has the right to to ask for it but more importantly let all micro services consume shots these shots as I said contained all the necessary information that we needed if each of these services can understand a JSON web token then you have distributed your authentication mechanism you have it somewhere else and you have a way of transporting identity information between your system they can send this back and forth between between them and it doesn't really change it's not an it's not a request object anymore it's an identity object that you pass around building a jot understanding libraries is a very small task it can easily easily be included in all of these when you deploy them so all you do is ask them to understand a jot obviously what I've been trying to say is you probably should translate this so have some guy in the front stateless not have to do much but all it has to do is take the rear by reference token and convert it to a by value token and then shoot this into your network so that's that's my talk on on OAuth and micro services and what I've tried to say here is that by using jobs we get a self-contained solution you can easily replicate this in every service all they need to do is accept this token on the incoming path it's completely standards-based it's secure and it's highly scalable all right thank you

Channel: Nordic APIs

Views: 181,757

Keywords: Security, 2014-10-22, API

Id: BdKmZ7mPNns

Length: 18min 32sec (1112 seconds)

Published: Fri Oct 24 2014