Web API Security – Patterns & Anti-Patterns
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Baier, Dominick
Web APIs and cross-platform (mobile) clients is pretty much the standard architecture for modern applications. These types of applications have also different security requirements compared to the intranet or the classic web. This talk is the result of almost five years of customer projects around the security of these modern applications – what works, what doesn’t, recommendations, dos and don’ts (and duhs).
 spirit i guess unwritten law you know security talks are after the lunch break suggested you know so now the little bit listen to my soft voice so this this year those that know me know that i'm i have a little bit of a authentication protocol ocd kind of thing going on so i'm i'm i'm obsessed by these things uh... but this this year is kind of like a different idea i want to do like a brain dump off you know stuff uh... we did with the baby i security for the last you know couple of years what worked what hasn't worked was you know what is something that many people don't know but should know stuff like that uh... so yeah you know i i don't like this patterns and anti-pattern thing or best practices whatever because i think it's it's all about context meadow so you know when i say this is a pattern on any pattern it might be the out the the opposite for you guys because you're doing stuff differently so you know take it with a grain of salt uh... whenever i think that is clearly a pattern and is clearly an anti-pattern i will point it out so here are my coordinate for if you want to contact me i'm going to use this thing called identity server for all my demos which isn't an implementation of a war of two and open my d connect and by the way the last thing that you know stand between us and being a real open source project was stickers so if you want stickers come to me after the talk i have a couple and yeah that's it so i have a laundry list of stuff i i i would love to go through i i never give this talk in sixty minutes was always longer so we'll see how that works out uh... but yeah let's get started basically where are we what kinds of applications of people building these days using using the baby i technology and well here we are it's not radically new adjust the names have changed that they want it was a time it was called that services we don't call them that services anymore because that might imply so and we don't want so where we want that the p i s uh... but it's basically it's it's a combination of that you are a native you are talking to that a p i s okay uh... the thing that's that's probably you know new for the last couple of years is that that types of clients that connect to your back ends are much more diverse you know like when i started like many years ago it was windows client with windows you know server and windows domain and everything was windows and you know you were like in this uh... not a little shielded world of active directory security that's all gone because you know we have so many clients which are not windows which don't care about windows at all uh... that's one observation the other one is uh... we have many clients now and the same users might use many clients to connect the same back end even you know throughout the day and by the way one really really important thing is uh... uh... that there are two terms that i tried to use as precisely as possible one is the user okay the user is the carbon based life form in your system yeah that's the human and the user using clients and the clients are the silicon based life form in your system like applications uh... and the same user might use different clients throughout the day he might start in the morning with his company laptop then go home use his phone on the you know on the train in the evening use his whatever other device but the back end might be always the same okay and that that that's kind of the thing we have we are um... we're designing for the across platform and that the p i is is a nice you know uh... least common denominator technology to make that happen and i mean it in the in the best way uh... that's the single security token service with me when we're gonna get to that that's often a part of that and think of it as outsourcing your authentication infrastructure because quickly speaking you need security in all of these boxes and it you know it's just insane in my opinion to reimplemented all one over and over again so we factored out as a service okay what we will get to that in more detail first pattern as a cell everything i'm saying in the next no probably for ever this only makes sense if you're running over as a cell so htp itself does not have any security built in uh... in the sense of data protection uh... replay protection server authentication integrity protection so everything they're doing is must run over as a cell there was actually a lot of talk about as a cell recently right apple wants to have a new policy in the app store that apps must use as a cell now if you're submitting an application which doesn't do that will not be accepted anymore okay as a list of important the issue is that developers and as a cell seem to have like a a problematic relationship somehow uh... google doesn't help you because if you say that he helped me well they help you with learning how to ignore as a cell in dot net this thing called a service point manager who has ever used that service point manager and it's called remote certificate validation callback and if you return a true from there it's like you know it never happened so yeah use as a cell enough said and then often i get the question yeah but my at least rate assess we are using as a cell about it's only to the load balancer and behind the load balancer we're doing clear text and you know i mean that is a valid architecture and and and the very common one the question i had you have to ask you at me now is okay so who has access to the cable between between the load balancer and the server and if you can confidently answer that question like it's only me okay so you only have to trust this guy if it's in the public cloud i don't know yeah uh... actually an architecture i'm seeing more and more often is to do as a cell till the load balancer using the public certificate with your public hostname and then doing another as a cell connection between the load balancer and the actual observer using a private certificate and that way you get like you know pretty much and to end transport protection without having to deal with the you know that the issues of the public certificates okay so that's that's an thing you can point your admin to next time even if that's that okay cool next thing so pretty much that the rest of the talk is about uh... authentication um... generally speaking uh... from an htp point of view there are two types of authentication methods you can use and i called an explicit versus implicit authentication explicit basically means um... you are authenticating the user and you're putting something onto the htp request that travels along to the api and the api will catch that and do some validation on that and you know authenticate the user somehow this is the the preferred model since you are explicitly doing something you are in full control when it happens yeah and typically we we we said the so-called authorization header and you know that there are no cross-domain restrictions as we see in other mechanisms death in death implicit authentication which is often used in browser based applications where the server sets a cookie and from that point on the browser will just replay that cookie back whenever he sees a request going to the same domain where the cookie came from as the name implies gives us no control because we can't control anymore when this cookie will be sent it will always be sent and that leads to some issues so i want to first talk about explicit authentication and then about the implicit one probably the the simplest pattern simple in the sense of there's no human involved here whenever we remove the humans from the architecture stuff gets much more easy only machines to deal with and they are kind of predictable um... so when you're doing a server to server style communication you have a server that talks to another server the way this typically works is you put something onto the authorization header and then the receiver accepts that and you know can make sure he trusts the caller um... the way you do that there are many many many ways yeah i mean shared secrets probably being the most common these days but basically that means you know the client the client knows a secret the server knows a secret if they agree that the same secret they you know they trust each other you have to ask yourself how secret are secrets when they are shared um... the other thing that people often do because they don't like transmitting the uh... or api keys would fall into into the same bucket um... the other approach that people often take are so-called shared signatures but basically you take stuff uh... on the client like the url the headers stuff sign that with an h-max signature transmit the signature over the wire and the receiving end does the same thing takes the same data signs it and compares the values and if the signatures match they can prove that they know a shared secret but without having to transmit the secret over the wire that's fine i mean technically there's no problem with that the only issue i have is uh... is the secret management part because now you're sharing secrets between clients and servers and the more clients and servers you have you have an exponential growth of secrets right for every permutation of of communication relationships you need a new secret and now they end up scattered all over your network that's why i typically like an approach called access tokens or token based authentication where the client goes to a token service authenticates with the token service gets back a token and uses the token to talk to the service how is that different well the secret is now shared between the client and the token service so when you have more clients and more services you only ever share secrets between the token service which is specialized to deal with these management issues so uh... think of it like this uh... decline goes to uh... and some sort of endpoint now authenticates with this endpoint he gets back a token and from that point on the client uses that token very similar to the idea of forms of indication right we go to one endpoint you authenticate once you get back a cookie and then you use the cookie to authenticate yeah just for machines there's a protocol for that it's called oof two and there's a thing called the client credentials flow which is actually exactly what i just described all of two brings some concepts to the table one is the thing called the authorization server which is the thing that manages the client secrets and also uh... produce the tokens it brings something on the table called scopes and scopes are just resources in your system so basically uh... an api is a scope in your system scopes are pretty abstract you can you could make him as make them as granular as endpoints they are like endpoint one endpoint two endpoint three it could be an application scope maybe you have many applications in your system you know accounting customer management whatever yeah so it's an abstract thing but the idea is the client goes to the token service as hey i'm client one this is how you can authenticate me give me a token for the scope one two three okay now the server can do some you know validation dust is client have access to these api's and so on if yes give him back a token and then use the token tokens have a lifetime tokens uh... are scoped as i said to whatever the client is allowed to access uh... and for validating those tokens that uh... the recipient doesn't need to write some custom code these are standard tokens there are standard modules you can block into your pipeline and you're you're done so that is a very common token format it's called chasing that tokens it's well as you can see it chasen data structure it has two parts to it one is the header which gives us a versioning information it has the claims which basically allows you to attach information to that caller uh... in the in the in the most minimal way days uh... the idea of the client and the scope this client has access to okay so it's pretty simple uh... so that the recipient uh... has to basically just validate this that that token at as i said it's it's pretty much standard software and then if you know the scope matches the the identity of the recipient it lets him in otherwise access denied so by the way that is the spec you want to read if you want to and now it becomes serious you can tell from the career font uh... things are getting serious now that and obviously that people seem to use ascii art to describe their intent and my favorite thing about it is they have uh... a pdf version so when you load that up it takes a while much much longer as a text version and you get this in the crate so let's get back to the text version anyways uh... when you're looking for that stuff there's a thing called a grant in in the spec and that the one i just described is is is called the client credential cram so you click on that you know it basically says what i just uh... said decline goes to the side the server gets back a token and then use the token to access the service and as you can see if you can formulate this htp post you can create a get a token so that should be doable and the whole idea between uh... it behind all of this make it as simple as possible so that any type of client can do that any client that can do this htp post should be able to get a token as opposed to a sample or wcf or w's trust for whatever way you first had to you know go to university and study xml and this was much harder um... the samples i'm showing you are in our github repo i will show you the github repo later on but basically everything you're seeing you can do yourself at home as well and and the idea is uh... you divide your application into two legs one is the token acquisition phase where you get the token and then the token usage phase so this this line of code here gets the token i've written a little helper library which does the form post for you uh... you pass in the token endpoint address declined id declined secrets say hey there was scopes that are called read and write give me a token and if i run that that's the response i'm getting the token response that's the access token that the jason web token format adjust uh... described it's basically a basic before you are a real version of the case and data structure including a signature so that nobody can change the data anymore after it's been created that's the lifetime of the token for the client knows okay now it uh... for the next three thousand six hundred seconds i can use that token and then then i need a new one and bearer is just uh... away to pass the token with the we don't have to discuss that here right now here's the access token contents decoded the header declined you know them that the claims uh... payload so to speak on the receiving and as i said there are standard components for that uh... microsoft has uh... uh... and and and and and and and and and and and and and and and and and and security middleware or something we just took that wrapped it made the configuration service a little bit nicer basically you say okay this token is expected to come from this server here to serve i have some metadata which we can pull down to configure the thing using you know like the expected key material and stuff like that and it says okay you know uh... i i expect is talking to have a scope called right otherwise the token you're sending me is not for me it might be for a different service but not for me okay that that's how you scope down these tokens so the distinction run as you should should uh... you know the up and if i call it i just echo back the claims from inside the token and it's working fine so that's the you know the most minimal uh... all of implementation that you can think of as i said it it that the part why this is easy is because there's no human involved it's just in two machines now i see the very interesting talk this morning from darrell we talk about status codes and there are two status codes we care the most in in this scenario and most people only use one yeah uh... and it's for one was a fall free and uh... especially if you think the microsoft stack they never made a distinction between four one and fall free was always for one uh... part of the reason i might be wrong is that the original htp spec wasn't crystal clear which one to use all the time but the good thing is they rewrote the htp spec just a couple of months ago to turn to make one spec into five specs to make it easier uh... but the good thing is that the separate back now for security and this has very clear instructions when to use which status code so the four one is basically that uh... that the key word here is uh... if the request lacks valid authentication okay so if you're so it is requiring a token i'm not sending you a token for one if the token is not coming from the expected issue for one if the token is expired for one let's try that uh... go back to my client my service requires authentication i don't set the token on the on the authorization header for one that basically tells the client i have a token here but it's not good anymore i need a new one the other uh... one is called for three the forbidden and that basically means you have a valid token but still the user or the client is not allowed to do what he's trying to do typically as a situation that you can't resolve on the client side because you know you're not allowed to do what you're trying to do that your token is good so getting a new one probably won't help so for example when i don't request the right scope here now just the read scope but my service is expecting at the right scope uh... and i run it again you're right thank you you see this time i should get a four three so that's that's very important for for for client developers to to to be able to distinguish between the two error conditions offer example a user has a valid token he tries to delete the customer but he's not allowed to to delete that customer for free would be the right error code to throw here probably okay now we enter the difficult territory of human centric authentication uh... you know humans they make me they make mistakes they typically don't deal very well with arbitrary one hundred twenty eight bit passwords so we have to do other you know things differently every common scenario up browser based applications and uh... often these applications start with you know you have like a maybe more like a classic mvc style application where you are you come from the server and then you read about his age x thing and you wanted to have these you know this validation callbacks and a little red boxes flying in and uh... you know all that cool stuff and then you added uh... chava script to your pages and they called a p i e spec ends now so basically is to do under the covers style of validation uh... and how you do off and the case in this scenario is basically you inherit the off and the case in from the hosting application cookies windows authentication basic authentication client certificate that's what i call implicit authentication because the browser takes care of that you did you just authenticate one and the browser will happily send the credential along is there an issue with cookie based authentication in browsers i heard it somewhere cookies are okay then you have to shut down your computer sorry that's that's that's that's the thing called c's rf or c serve as the cool kids say and c serve basically means you know exactly what i would have just described to you yeah basically you're looking in you know you're opening up a browser tab in your in your browser you authenticate you get an authentication cookie and then you can just call your a p i is from within your age x but what happens if the same user goes to uh... and opens a new tab and goes to you know china hack shack dot com and what happens if that that domain makes calls to your a p i what will the browser do it was and cookie right i mean that's what they're supposed to do so basically you can remote control an application but while impersonating an already authenticated user every time i'm i'm describing that i i have some people in the audience saying i don't believe you this can't be the way it is that would be a clearing security hole well but that it is the way it is okay i'm the day there was a really nice hack recently in in germany last year where they had the couple of popular websites and injected malicious chava script and what is chava sped was doing is basically tried to contact while you know what the download it to your home computer it tried to access the typical i p addresses where your home routers might live like one nine two one six eight zero one and it turns out that there are some you know home routers manufacturers that have these you know the distance that admin u i's and because you're doing the ad you know that you are you're administrating your home router every single day that's why you need a persistent cookie okay good second uh... first fault second fault was there that you are allowed to manipulate state using get requests for example slash conflict slash dns slash ad question mark i p equals so what happens if i can control your dns server i can do everything i want to your home network right and that was c-surf if anybody in the room doesn't believe me that that's what happened it's it's cross-site request for three impersonating someone in the same browser uh... in the combination with a really crappy htp api so yeah it's real and we don't have much control over that in the browser because you know process to it implicitly for us how do we protect against that in in mvc is mvc also part of the problem it is just a p i's so in mvc it's it's kind of built-in right you have you you know you can do html dot validae uh... anti-fortuary token that doesn't html helper for that desert attribute you can put on the on the form post actions that validates uh... however that works in in a better p i just didn't exist there we we have that as part of sample code now it's called validate htp and default retoken the way it works is when you render a form you have this hidden field in your form with uh... you know a random number at the same time date they set a cookie with the same random number or or a related one at least at the right for on uh... from a master secret now when you post back in mvc you post back the cookie and you post back the hidden field if they both match you know that the post that comes from the same domain where you render the form in the first place for for a p i's it's a little bit more work because basically what you have to do is you have to send back the cookie and uh... get this hidden uh... field and put it on a header and send the header along and then this attribute here will validate the cookie and the header that's how microsoft proposed uh... a solution they the fact that when microsoft put doesn't put something into their framework it means that they're not sure yet if that's the final solution and it turns out like next version this this this appeared again basically when you're opening them the baby p i version two templates there is no cookie cookie authentication allowed anymore okay so if you stick an a p i controller into your mvc application you will be surprised because it will always be anonymous users they turned off the cookie authentication you can turn it on again but you'd now know what happens okay so in my in my opinion cookies are great for that you are is they are not great for that a p i's for that a p i's tokens are great so how do we authenticate the user if we can't use cookies well the low-hanging fruit would be this right you can use them in password yeah that there's a thing called basic authentication in htp let's just send the name of the user as a basic authentication header uh... and do it like this there are many many problems with with this approach it seems simple uh... at first but obviously htp is stateless which means we would have to transmit the password for every single request which means we would we need to to uh... prompt the user for his password for every single request always storage both is not great password validation should be really costly these days to to protect against brute force attacks yeah so uh... there the recommendation from ovasp is right now it should take it should take half a second to validate the password as a good way we do that is we take the password add a random number to it hashi it hashi it hashi it for fifty thousand times okay so keep the cpu busy uh... and then and attack i would basically need like half a second for one password guess that means if he sent the password along every time then we need half a second to validate it and then we have to rest for our payload you can opt optimize that of course but the point is the probability of accidentally exposing that long-lived credential the password is very high okay so again we we don't want to do that back to oaf all of us you know all of the rescue there are options in all of uh... not for only validating uh... authenticating clients but also for authenticating users and there are two fundamental approaches in all of one is not so much recommended and one is the more recommended one uh... them not so much recommended one is that you let your client application deal with the password you write your own login dialogue with you know you can impress but you know click here to log in that the client application sense the password to the server gets a token back and uses that token now i mean that that's still better than using the token for every single record at the password for every single request but this is only useful for trucker clients that you trust right i mean you might not even write that client yourself it might be a third party that that that that writes and declined against your public a p i n point so maybe you you don't want to expose your users password to arbitrary apps on the android store and the other thing is that obviously you have to re-implement all of that you look in you are in looking logic for every client you're writing the other more uh... recommended approach is to handle all of the authentication on the old war of authorization survey itself such as for the record i'm i'm i'm showing you the first approach very quickly so that you know how it works it's very simple you write a client application it makes a post to the token endpoint it uh... sense along the scope it sense along its client id in secret it sets the it sense the username of the user the password of the user and you get back a token okay same idea as before but now with additional user credentials as i said this is implies that you handle all of the little of the authentication on the client that much more common approach is called the implicit flow and this is has um... many many advantages so one of the advantages is basically your client application doesn't need to know anything about credentials okay so the idea is your client application just hands off control to the old war of service a hey he's a user he wants to authenticate make it happen set me back a token on error message i don't care what you have to do to make it happen it might be a brand new user never looked in before he has to register he he he he has to go for a complete record registration workflow email confirmation all these things it might be an existing user that just looks in chop down it might be an existing user which maybe has to read confirm your terms and services because you change them after the last time you looked in the client doesn't care it's the service job okay and the way this works is you do a uh... you go to the so-called authorized endpoint pass in the client ID say which scope you want to have access to say where to call me back once done and say give me a token now that hands off the control to the server now the server can do whatever logic is necessary to you know to make it happen show a login page you know that the user login have something called consent consent is an interesting uh... uh... idea where you basically give the user a summary of the authentication process once it's done okay so you can say that okay you know what we think you are a dominic and we think you're using an application called code flow client demo and this thing wants to know for example what's your your your user id and wants to access an api called read data and an api called write data are you sure you want that so now i i i really really got a got a question from from the audience saying like okay can this protect my grant my on the internet i said no obviously not i mean i i'm not going to my reach what what standing there okay because if grant my precious yes then that's what's what's going to happen right this application will get a token to call the api on behalf of grant mark it's interesting concept it is more common for public facing applications not so much common for enterprise style applications and you can turn it on alternative based on on the client uh... that's how to do that with us a constant screen looks like for example all yeah and they also said okay you you you're client will not be able to see the password at least if it's not reading keystrokes the last step after an arbitrary number of steps in between you get back the access token delivered back to the client application uh... the way this works is depends on many per protocol parameters it might be a form post it might be a get request uh... typically on uh... when you when you think that request it's on at the soak after the so-called hash fragment hash fragments prevent that stuff being sent to another server again so you want to make sure it stays in your client application uh... and so on as an example of that uh... let's use this one the chava script client here by say hey give me an access token this triggers the authentication process i'm authenticating uh... bob and bob every system should have a bob uh... constant screen yeah give give me that token and here it is so that's the implicit flow that is the by far the most common flow and you are you've done that many many hundred times they are typically when you download an application from the app store you authenticate you might not see that it's a browser behind the scenes big if they are clever and style the webpage exactly like the surrounding native app you might not even see that yeah but it's typically a browser window going going up going to the server and letting the server do whatever is necessary to do give you back a token so that's the implicit flow and again that there are many many more options that uh... the intention of this talk is what to give you like pointers where you want to follow up on on on the details because obviously there's you know i could talk many days about that the next pattern which is enabled implicit flow is federation or social logins or you know enterprise logins yeah again the client application using the implicit flow model it hands off control to the server now how the server authenticates the user is totally up to the server the only thing that you know the client wants is it is an access token in the end okay so i am we've briefly seen that so when i do a log out here and come back to my uh... application and do uh... access token you see here uh... i i i have options here yeah i'm dead as a local login that there are external logins so you know uh... if if this authorization service configured to allow external logins for this application then then it can give the user more options here so maybe maybe i want to connect to my enterprise uh... authentication thing so i can use a dfs maybe i wanna support you know uh... social logins or maybe i want to do you know cloud stuff whatever so let's let's let's press google same constant screen again declined application doesn't know the difference as long as it gets a token that will be valid for the for the api next one i'm doing in time that is now one of the the most interesting ones i think yeah so that the first part was mechanics a lot you know like okay that this flow that this flow that this flow once you you know cut the hang off of these flows you will at some point said okay how long should this talk would be valid for and basically we have a couple of not see it at that that we can turn based on what type of application you're writing as a uh... there's obviously that the style of application where you want to use that to log in once and then he will never be bothered again in his whole lifetime with a log in dialogue so i i just recently got uh... the answer on the issue track i think what's your maximum lifetime for tokens and i think it's in dot max value does that work for you it is that's that's fine i mean it it's second but it's still a couple of decades i think uh... so that that should work other other customers want to write applications where the user should periodically log in maybe once a week once a day maybe it is so you know sensitive that you know you want made one make sure that that he has to re-authenticate a uh... multiple times so there are two not state that you can turn to find you in this behavior the first the first one is the access token lifetime itself yeah basically meaning the short of the access token lifetime is the more often the client has to go back to the server get a new one and yet i want is that said the single sign-on session the user has with the server with the authorization server meaning the short at this session is the more often you will see a login screen so basically on on one end how often do i need tokens on the other end how often do i need login screens i give you google as an example they do uh... a single sign-on cookie for fourteen days so you only have to re-authenticate with them every two weeks but the access tokens are by default just one hour okay so the client application has to get a new access token every hour but only will show the login page every fourteen days well so that's like they are trade-off and actually they did they made some research that uh... it's more secure to not show the login page as often because then you just get used to typing in their password in everything that looks like a password box and if you educate them that this shouldn't happen that often then they are more cautious about it same goes by the way for password change policies it's it's uh... that there's some research saying if you choose one really good password it will be better than the one you have to pick every forty days in your company for example so oh yeah and cookies have sliding expiration as well which tokens typically don't have tokens have a fixed lifetime and actually proc directly after this talk proc will show a client library we've been working on which can automate much of these renewal of tokens so there's a really interesting technique for chava script basically when you say that okay the token is valid for one hour but the cookie is valid for fourteen days where and then you can write some code that monitors the lifetime of the token and when it comes to the end like sixty seconds before the end of the of the token lifetime you can open an invisible eye frame going back to the token service getting a new token and replacing the new one with the old one and as long as there's no login prompt this will work and we've written such a library inspired by the way how google does it they do it exactly like that and proc will show you that after this session now there's an interesting technique which many people don't know about which gives you better control over token lifetime and it's called reference token so i've just shown you the chasing that token right so it's a chasing data structure you you know you see let you sign it as a lifetime on it yeah uh... and you ship it chasing that tokens are very hard to revoke before their lifetime and so let's say for example you lose you losing your phone for example and you want to go to a website maybe say like you know real big red button i lost my phone please invalidate all my access tokens here it's hard to do with chasing that tokens because you know that they're self-contained as long as they are out there they're good you get much more flexibility actually when you don't ship these data structures yes so the idea with reference tokens is that you keep the actual data structure on the authorization server but only ship a handle to that token basically you will ship that handle back uh... from that token the client will send the handle to the service to the api and the api will do a back channel communication back to the authorization service saying that is this handle valid if yes give me the content of the token and and from a from a application point of view this doesn't make any difference it's it's just a different way how to validate the token which means that now you can provide a programmatic ways and self service ways to revoke the tokens before they expire okay for these customers or people that that that want to have basically tokens that live forever that is a nice middle ground here you can issue a really long-lived token but have the ability to revoke it at any point in time so that is often you know the answer to the question i'm writing a mobile application i want you know it uses the site to look in once but i want to have protection whenever the talk that the phone gets lost or you know things like that for example what uh... microsoft is doing is whenever you change your passport in asia active directory they invalidate their tokens which i think is a little harsh to be honest uh... i would have maybe expected like resetting the passport would trigger that uh... anyways we have in in in identity so that we have both uh... a product programmatic way of doing that as death and revocation endpoint that you can call or desert self service portal where the user can revoke tokens and i will show you both in a second actually wish you both now makes much more sense so yeah let let me show you a different client and that that's more mostly like a proof of concept how to write a native client there so that's not a browser yeah uh... but if i uh... get it one when i get a token i basically open an embedded browser like a web view freaks me out and then i you know authenticate somehow did the idea is the same decline doesn't want to know how that works here we just you know get getting called back with a token hello google uh... here we are you see he has the access token and that looks pretty big so that must be a jason lep token yeah uh... if i hope sorry if i go to my configuration for this client in identity server and said the access token type to reference and make the same thing again access token google you see now this talk is much smaller so when i now call the service you know it works but now at the same time the user can go let's say to to their self service portal hdps which is a local host of course application permissions you know sign in and then say hey i lost my phone and now i call the service again unauthorized but that's that that's a nice in between way of dealing with long-lived tokens i think when you ask certain industry experts or other companies that produce token services like in asia for example that the answer is often it's called refresh token refresh token is the is the default answer and there's a thing called refresh tokens in in the specification of all of but i don't think i really don't think that this is a good fit for mobile net applications basically i'll show you what the way this works is that you are adding a special scope to it called offline access and when you when you said offline access you get back a special token called the refresh token and this refresh token can be used to get new access tokens for a very long time without having the user being involved again so the way this works is we say hey give me a give me this offline access thing this time you can't uh... you can't uh... get the token directly you have to say give me a so-called authorization code that will basically mean you get back uh... a code and then the the the application must do a back channel communication to the authorization so i say hey it's me here's my id here's my secret and here's my code okay and you will get back an access token and the refresh token now using this technique on on client applications mobile devices implies that you ship your client secret to the mobile device does that make any sense it is called a secret right okay um... and you get back in return a refresh token which is a very very very long-lived token and with this refresh token you can get new access tokens so what is what what makes this better than having just long-lived reference tokens that you can revoke anytime where this thing was designed for originally is for server side applications so when you are in the data center and let's say you're having this dispatch job um... running every every thirty days that that wakes up needs to access data of the user on behalf of the user and do some calculation you know write something to a database go to sleep again you wanna make sure that never ever uh... this dispatch job uh... is missing the token it needs to access the data of the user okay so you need like a way to get to have long-lived tokens then this is a nice approach and so basically you store the access token in the back end you store the refresh token in the back end and you store your client id and client secret in the back end and then you can get new tokens whenever you need to but having at the same time the option to revoke access again to your data by removing the refresh token from from from the database when you hear refresh tokens as the answer to your long-lived token problem uh... i wouldn't i wouldn't immediately believe that refresh tokens are for servers they are good for servers that's where they were designed for in my opinion long-lived reference tokens are much more suitable for the client side of applications where you wanna have this long-lived semantics and don't have to re-authenticate the user if you want to have something in between like google does you know then then play with the two nobs yeah that that i that that i told you like sir cookie lifetime access token lifetime and find the right the right you know balance in between that that works for you the red the red the revocation endpoint i i am uh... mentioned that and all your i can show you a sample of the the refresh token thing as well uh... so that's a a server side application as i said that's where i think it it it it it fits the best uh... so when i don't request the offline access scope you know i'm doing this the standard flow here that's just google again but type typing in bob is actually faster i get my my code code here i get the token and i have my stuff right uh... he has an access token in in that case it's a reference token but that's just coincidence yeah but if i now add to the uh... offline offline access scope to it say okay now you see that on the constant screen we always trigger the constant screen uh... if enabled for offline access because it's such a highly privileged thing to request from you even if you say remember my decision you will get this to see the content screen again get the code get the token and now you see here just now the refresh token and now you can go to the application you know and then we have our claims here he has the access token he has the expires ad and here's my refresh token and at any point in time now the server can say refresh the token which will give you a new access token a new refresh token when you watch here the lifetime you will basically renew the lifetime into the future and if you don't want it anymore you can say revoke the refresh token and when you then refresh the token you get an error it's gone that is how it looks like in dropbox they call it my apps but it is really refresh token management under the covers how do you get rid of long-lived access tokens and that's it we have time for questions uh... thank you very much so far there's the slide x are here and if you have any questions feel free to ask them now otherwise enjoy the rest of the conference thank you and get stickers if you want them questions happy despy as a
 spirit i guess  unwritten law you know security talks are after the lunch break  suggested you know  so now the little bit  listen to my soft voice  so this this year  those that know me know that i'm i have a little bit of a  authentication protocol ocd  kind of thing going on so i'm i'm i'm obsessed by these things  uh... but this this year is kind of like a different idea i want to do like a  brain dump  off you know stuff  uh... we did with the baby i security for the last you know couple of years  what worked what hasn't worked was you know  what is something that many people don't know but should know stuff like that  uh... so yeah  you know i i don't like this patterns and anti-pattern thing or best  practices whatever because i think  it's it's all about context  meadow so you know when i say this is a pattern on any pattern it might be the  out the the opposite for you guys because you're doing stuff differently so you  know take it with a grain of salt  uh... whenever i think that is clearly a pattern and is clearly an anti-pattern  i will point it out  so  here are my  coordinate for if you want to contact me  i'm going to use this thing called identity server for all my demos which  isn't an implementation of a war of two  and open my d connect and by the way  the last thing that you know stand between us and being a real open source  project was stickers  so if you want stickers come to me after the talk i have a couple  and yeah that's it so i have a laundry list of stuff i i i would love to go  through  i i never give this talk in sixty minutes  was always longer so we'll see how that works out  uh...  but yeah  let's get started  basically where are we what kinds of applications of people building these  days using  using  the baby i technology and well here we are  it's not radically new adjust the names have changed  that they want it was a time  it was called that services we don't call them that services anymore because  that might imply so  and we don't want so  where we want that the p i s  uh... but it's basically it's it's a combination of that you are a native  you are  talking to that a p i s  okay  uh... the thing that's that's probably you know  new for the last couple of years is  that that types of clients that connect to your  back ends  are much more diverse you know like when i started like  many years ago it was windows client  with windows you know  server and windows domain and everything was windows and you know you were  like  in this uh... not a little  shielded world of active directory security that's all gone  because you know we have so many clients which are not windows which don't  care about windows at all  uh... that's one observation  the other one is uh...  we have many clients now and the same users might use many clients to connect  the same back end even you know throughout the day  and by the way one really really important thing is  uh... uh... that there are two terms that i tried to use as  precisely as possible one is the user  okay the user is the carbon based life form  in your system  yeah that's the human  and the user using clients  and the clients are the silicon based life form  in your system  like applications  uh... and the same user might use different clients  throughout the day he might start in the morning with his company laptop then go  home use his phone on the you know on the train  in the evening  use his whatever  other device  but the back end might be always the same  okay and that that that's kind of the thing we have we are um...  we're designing for the across platform  and that the p i is is a nice  you know  uh... least common denominator technology to make that happen  and i mean it in the in the best way  uh...  that's the single security token service with me when we're gonna get to that  that's often a part of that  and think of it as outsourcing  your authentication infrastructure because quickly speaking you need security  in all of these boxes  and it you know it's just insane in my opinion to reimplemented all one over  and over again so we factored out  as a service  okay what we will get to that in more detail  first pattern  as a cell  everything i'm saying in the next no  probably for ever  this only makes sense if you're running over as a cell  so htp itself does not have any  security built in  uh... in the sense of data protection  uh... replay protection  server authentication integrity protection  so everything they're doing is must run over as a cell  there was actually a lot of talk about as a cell recently right apple  wants to have a new policy in the app store that  apps must use as a cell now if you're submitting an application which doesn't  do that  will not be accepted anymore  okay as a list of important  the issue is that  developers and as a cell seem to have like a  a problematic relationship somehow  uh... google doesn't help you because if you say that he helped me  well they help you with  learning how to ignore as a cell  in dot net this thing called a service point manager  who has ever used that service point manager  and it's called remote certificate validation callback  and if you return a true from there  it's like you know it never happened  so yeah use as a cell  enough said  and then often i get the question yeah but my at least rate assess  we are using as a cell about it's  only to the load balancer  and behind the load balancer we're doing clear text  and you know i mean that is a valid architecture and and and the very common  one  the question i had you have to ask you at me now is okay so who has access to the  cable between between the load balancer and the server  and if you can confidently answer that question like it's only me  okay so you only have to trust this guy  if it's in the public cloud  i don't know  yeah  uh... actually an architecture i'm seeing more and more often is to do  as a cell till the load balancer using the public certificate with your public  hostname and then doing another as a cell connection between the load balancer  and the actual observer  using a private certificate  and that way you get like you know pretty much and to end transport  protection without having to deal with the you know that the issues of the  public  certificates  okay so that's  that's an thing you can point your admin to next time  even if that's that  okay cool  next thing  so pretty much that the rest of the talk is about uh... authentication  um...  generally speaking  uh... from an htp point of view  there are two types of authentication methods you can use and i called an  explicit versus implicit authentication  explicit basically means  um... you are  authenticating the user  and you're putting something onto the htp request that travels along to the  api and the api will catch that and do some validation on that  and you know  authenticate the user somehow  this is the  the preferred model  since you are explicitly  doing something you are in full control when it happens  yeah and typically we we we said the so-called authorization header  and you know that there are no cross-domain restrictions as we see in  other  mechanisms  death in death implicit authentication which is often used in browser based  applications where the server sets a cookie  and from that point on the browser will just replay that cookie back whenever  he sees a request going to the same domain  where the cookie came from  as the name implies gives us no control because we can't control anymore when  this cookie will be sent it will always be sent and that leads to some issues  so i want to first talk about explicit authentication  and then about  the implicit one  probably the  the simplest pattern  simple in the sense of there's no human involved here  whenever we remove the humans from the architecture stuff gets much more easy  only machines to deal with and they are  kind of predictable  um...  so when you're doing a server to server style communication you have a server  that talks to another server  the way this typically works is you put something onto the authorization header  and then the receiver accepts that and you know can make sure he trusts the caller  um...  the way you do that there are many many many ways yeah i mean  shared secrets probably being the most common these days  but basically that means you know the client the client knows a secret the  server knows a secret  if they agree that the same secret  they you know they trust each other  you have to ask yourself how secret are secrets when they are shared  um...  the other thing that people often do because they don't like transmitting  the uh... or api keys would fall into into the same bucket  um...  the other approach that people often take are so-called shared signatures  but basically you take stuff  uh... on the client like  the url the headers stuff  sign that with an h-max signature  transmit the signature over the wire and the receiving end  does the same thing takes the same data signs it  and compares the values and if the signatures match they can prove that  they know a shared secret  but without having to transmit the secret over the wire  that's fine  i mean technically  there's no problem with that  the only issue i have is uh...  is the secret management part  because now you're sharing secrets between clients and servers and the more  clients and servers you have  you have an exponential growth of secrets  right for every permutation  of of communication relationships you need a new secret  and now they end up scattered  all over your network  that's why i typically like an approach called access tokens or token based  authentication where  the client goes to a token service  authenticates with the token service gets back a token and uses the token to  talk to the service  how is that different  well the secret is now shared between the client and the token service  so when you have more clients and more services you only ever share secrets  between the token service which is specialized to deal with these management  issues  so  uh... think of it like this  uh... decline goes to uh... and some sort of endpoint now authenticates with  this endpoint  he gets back a token  and from that point on the client uses that token  very similar to the idea of forms of indication right  we go to one endpoint you authenticate once  you get back a cookie  and then you use the cookie to authenticate yeah  just for machines  there's a protocol for that  it's called oof two  and there's a thing called the client credentials flow which is actually  exactly what i just described  all of two brings some concepts to the table one is the thing called the  authorization server which is the thing  that manages  the client secrets and also  uh... produce the tokens  it brings something on the table called scopes  and scopes are just resources in your system so basically  uh... an api is a scope in your system  scopes are pretty abstract you can  you could make him as make them as granular as endpoints  they are like endpoint one endpoint two endpoint three  it could be an application scope maybe you have many applications in your  system  you know  accounting  customer management whatever yeah so it's an abstract thing but the idea is  the client goes to the token service as hey i'm client one  this is how you can authenticate me  give me a token for the scope  one two three  okay  now the server can do some  you know  validation  dust is client have access to these api's and so on  if yes  give him back a token  and then use the token  tokens have a lifetime tokens uh... are scoped as i said to  whatever the client is allowed to access  uh... and for validating those tokens that uh... the recipient doesn't need to  write some custom code  these are standard tokens there are standard modules you can block into your  pipeline and you're you're done  so  that is a very  common token format  it's called chasing that tokens  it's well as you can see it chasen data structure  it has two parts to it one is the header which gives us a versioning  information it has the claims  which basically allows you to attach information to that caller  uh... in the in the in the most minimal way  days uh...  the idea of the client and the scope this client has access to  okay so it's pretty simple  uh... so that the recipient  uh... has to basically just validate this that that token at as i said it's  it's pretty much standard software  and then if you know the scope matches the  the identity of the recipient it lets him in otherwise access denied  so  by the way  that is the spec you want to read  if you want to  and now it becomes serious you can tell from the career font  uh... things are getting serious now  that and  obviously that people seem to use ascii art  to describe their intent  and my favorite thing about it is  they have uh... a pdf version  so when you load that up  it takes a while much much longer as a text version  and you get this  in the crate  so let's get back to the text version  anyways uh... when you're looking for that stuff  there's a thing called a grant in in the spec and that the one i just described  is is is called the client credential cram so you click on that  you know it basically says what i just uh... said  decline goes to the side the server gets back a token and then use the token to  access the service  and as you can see  if you can  formulate this htp post  you can create a get a token  so that should be doable  and the whole idea between uh... it behind all of this  make it as simple as possible so that any type of client can do that any client  that can do this htp post  should be able to get a token  as opposed to a sample or wcf or w's trust for whatever way you first had to  you know go to university and study xml  and this was much harder  um... the samples i'm showing you are in our github repo i will show you the  github repo later on but basically everything you're seeing you can do  yourself at home as well  and and the idea is uh... you divide your application into two legs one is the  token acquisition phase  where you get the token and then the token usage phase  so this  this line of code here  gets the token i've written a little  helper library which does the form post for you  uh... you pass in the token endpoint address declined id declined secrets say  hey there was  scopes that are called read and write  give me a token  and if i run that  that's the response i'm getting the token response that's the access token  that the jason web token format adjust uh... described  it's basically a basic before you are a real version of the case and data structure  including a signature so that nobody can change the data anymore after it's been  created  that's the lifetime of the token for the client knows okay now it uh... for the  next three thousand six hundred seconds i can use that token and then then i need  a new one  and bearer is just uh... away to pass the token with the we don't have to  discuss that here right now  here's the access token contents decoded  the header  declined you know them  that the claims uh...  payload so to speak  on the receiving and as i said there are standard components for that uh...  microsoft has uh...  uh... and and and and and and and and and and and and and and and and and and  security middleware or something  we just took that wrapped it made the configuration service a little bit  nicer  basically you say okay  this token is expected to come from this server here to serve i have some  metadata which we can pull down to configure the thing using you know  like the expected key material and stuff like that  and it says okay you know  uh... i i expect is talking to have a scope called right  otherwise the token you're sending me is not for me  it might be for a different service but not for me  okay that that's how you scope down  these tokens  so the distinction run as you should should uh... you know the up  and if i call it i just echo back the claims from inside the token  and it's working  fine  so that's the you know the most minimal  uh... all of implementation that you can think of  as i said it it that the part why this is easy is because there's no human involved  it's just in two machines  now i see the very interesting talk this morning  from darrell  we talk about status codes  and there are two status codes we care the most in in this scenario and most  people only use one  yeah  uh... and it's for one was a fall free  and uh...  especially if you think the microsoft stack  they never made a distinction between four one and fall free was always for one  uh...  part of the reason  i might be wrong is that the original htp spec wasn't crystal clear  which one to use all the time but the good thing is they rewrote the htp spec  just a couple of months ago  to turn to make one spec into five specs  to make it easier  uh...  but the good thing is that the separate back now for security and this has very  clear instructions when to use which status code  so the four one  is basically that uh... that the key word here is  uh... if the request lacks valid authentication  okay so if you're so it is requiring a token i'm not sending you a token for one  if the token is not coming  from the expected issue  for one  if the token is expired  for one  let's try that  uh... go back to my client  my service requires authentication  i don't set the token  on the on the authorization header  for one  that basically tells the client  i have a token here but it's not good anymore i need a new one  the other  uh...  one is called for three  the forbidden  and that basically means you have a valid token but still  the user or the client is not allowed to do what he's trying to do  typically as a situation that you can't resolve on the client side  because you know  you're not allowed to do what you're trying to do  that your token is good  so getting a new one probably won't help  so for example when i don't  request the right scope here  now just the read scope but my service is expecting at the right scope  uh... and i run it again  you're right  thank you  you see this time  i should get  a four three  so that's that's very important for for for client developers to to to be able to  distinguish between the two  error conditions  offer example a user has a valid token he tries to delete the customer but he's  not allowed to to delete that customer  for free would be the right error code to throw here probably  okay  now we enter the  difficult territory  of human  centric authentication  uh... you know humans they make me they make mistakes they typically don't  deal very well with arbitrary one hundred twenty eight bit passwords  so we have to do other  you know things differently  every common scenario up browser based applications and uh...  often these applications start with you know you have like a  maybe more like a classic mvc style application where you are you come from  the server  and then you read about his age x thing  and you wanted to have these you know this validation callbacks and a little  red boxes flying in and uh... you know all that cool stuff  and then you added uh...  chava script to your pages and they called  a p i e spec ends  now so basically is to do under the covers style of  validation  uh...  and  how you do off and the case in this scenario is basically you inherit the  off and the case in from  the hosting application  cookies  windows authentication  basic authentication client certificate that's what i call implicit  authentication because the browser takes care of that you did you just  authenticate one and the browser will happily send  the credential along  is there an issue with cookie based authentication in browsers  i heard it somewhere  cookies are okay then you have to shut down your computer sorry  that's that's that's that's the thing called c's rf or c serve as the cool  kids say  and c serve basically means you know  exactly what i would have just described to you yeah basically you're  looking in you know you're opening up a browser tab in your in your browser you  authenticate  you get an authentication cookie  and then you can just call your a p i is from within your age x  but what happens if the same user goes to uh... and opens a new tab and goes to  you know  china hack shack dot com  and what happens if that that domain  makes calls to your a p i  what will the browser do  it was and cookie right i mean that's what they're supposed to do  so basically you can remote control an application  but while impersonating an already authenticated user  every time i'm i'm describing that i i have some people in the audience saying  i don't believe you  this can't be the way it is that would be a clearing security hole  well but that it is the way it is  okay i'm the day there was a really nice hack recently  in in germany last year  where they had the couple of popular websites and  injected malicious chava script  and what is chava sped was doing is basically tried to contact while you  know what the download it to your home computer  it tried to access  the typical i p addresses where your home routers might live like one nine  two one six eight zero one  and it turns out that there are some you know home routers  manufacturers that have these  you know the distance that admin u i's  and because you're doing the ad you know that you are you're administrating  your home router every single day  that's why you need a persistent cookie  okay  good  second  uh... first fault second fault was  there  that you are  allowed to manipulate state using get requests  for example  slash conflict slash dns slash ad  question mark i p equals  so what happens if i can control your dns server  i can do everything i want to your home network right  and that was c-surf  if anybody in the room doesn't believe me that that's what happened  it's it's cross-site request for three impersonating someone in the same  browser  uh... in the combination with a really crappy  htp api  so yeah it's real  and we don't have much control over that in the browser because you know  process to it implicitly for us  how do we protect against that in in mvc  is mvc also  part of the problem  it is just a p i's  so in mvc it's it's kind of built-in right you have you you know you can do  html dot validae uh... anti-fortuary token that doesn't html helper for that  desert attribute you can put on the on the form post actions that validates  uh...  however that works  in in a better p i just didn't exist there  we we have that as part of sample code now it's called validate htp and  default retoken  the way it works is when you render a form  you have this hidden field in your form with uh... you know a random number  at the same time date they set a cookie with  the same random number or  or a related one at least at the right for on uh... from a master secret  now when you post back in mvc you post back the cookie and you post back the  hidden field if they both match  you know that the post that comes from the same domain where you render the  form in the first place  for for a p i's it's a little bit more work because  basically what you have to do is you have to send back the cookie  and  uh... get this hidden uh... field and put it on a header  and send the header along and then this attribute here will validate the cookie  and the header  that's how microsoft proposed uh... a solution  they  the fact that when microsoft put doesn't put something into their framework  it means that they're not sure yet if that's the final solution  and it turns out like next version this this this appeared again  basically when you're opening them  the baby p i version two templates  there is no cookie  cookie authentication allowed anymore  okay so if you stick an a p i controller into your mvc application  you will be surprised because it will always be anonymous users  they turned off the cookie authentication you can turn it on again  but you'd now know what happens  okay so in my in my opinion  cookies are great for that you are is  they are not great for that a p i's  for that a p i's  tokens are great  so  how do we authenticate the user if we can't use cookies  well the low-hanging fruit would be this right  you can use them in password yeah  that there's a thing called basic authentication in htp  let's just send the name of the user  as a basic authentication header  uh... and do it like this  there are  many many problems with with this approach it seems simple  uh... at first  but obviously htp is stateless which means we would have to transmit the  password for every single request  which means we would we need to to uh... prompt the user for his password for  every single request  always storage  both is not great  password validation should be really costly these days to to protect against  brute force attacks  yeah so uh... there  the recommendation from ovasp is right now it should take  it should take half a second to validate the password  as a good way we do that is we take the password  add a random number to it hashi it hashi it hashi it for fifty thousand times  okay so keep the cpu busy  uh... and then and attack i would basically need like half a second for  one password guess  that means if he sent the password along every time  then we need half a second to validate it  and then we have to rest for our payload  you can opt  optimize that of course but the point is  the probability of accidentally exposing that  long-lived credential the password is very high  okay so again we we don't want to do that  back to oaf  all of us you know all of the rescue  there are options in all of uh... not for only validating uh...  authenticating clients but also for authenticating  users and there are two fundamental approaches in all of  one is not so much recommended and one is the more recommended one  uh... them not so much recommended one is that you let your client application  deal with the password  you write your own login dialogue with you know you can impress but  you know  click here to log in  that the client application sense the password to the server gets a token back  and uses that token  now i mean that that's still better than using the token for every single  record at the password for every single request  but  this is only useful for trucker clients that you trust  right i mean  you might not even write that client yourself it might be a third party that  that that that writes and declined against your public a p i n point so  maybe you you don't want to expose your users password to arbitrary apps on the  android store  and  the other thing is that obviously you have to re-implement all of that you  look in you are in looking logic for every client you're writing  the other more uh...  recommended approach  is to handle all of the authentication on the old war of authorization  survey itself  such as for the record i'm i'm i'm showing you the first approach very  quickly  so that you know how it works  it's very simple you write a client application it makes a post to the  token endpoint  it uh...  sense along the scope  it sense along its client id in secret  it sets the it sense the username of the user  the password of the user  and you get back a token  okay same idea as before  but now with additional user credentials  as i said this is implies that you handle all of the little of the  authentication on the client  that much more common approach is called the implicit flow  and this is has um...  many many advantages  so one of the advantages is basically your client application doesn't need to  know anything  about credentials okay  so the idea is your client application just hands off control to the old  war of service a hey  he's a user  he wants to authenticate  make it happen  set me back a token  on error message  i don't care what you have to do to make it happen it might be  a brand new user never looked in before he has to register he he he he has to go  for a complete record registration workflow email confirmation all these  things  it might be an existing user  that just looks in  chop down  it might be an existing user which maybe has to read  confirm your terms and services because you change them after the last time you  looked in  the client doesn't care it's the service job okay  and the way this works is you do a uh... you go to the so-called authorized  endpoint pass in the client ID  say which scope you want to have access to  say where to call me back once done  and say give me a token  now  that hands off the control to the server now the server can  do whatever logic is necessary to you know to make it happen  show a login page you know that the user login  have something called consent consent is an interesting uh...  uh... idea  where you basically give the user  a summary of the authentication process once it's done  okay so you can say that okay you know what we think you are a dominic  and we think you're using an application called code flow client demo  and this thing  wants to know  for example what's your your your user id and wants to access an api called  read data and an api called write data  are you sure you want that  so now i i i really really got a got a question from from the audience saying  like okay can this protect my grant my on the internet  i said no obviously not i mean i i'm not going to my reach what what standing  there  okay because if grant my precious yes  then that's what's what's going to happen right  this application will get a token to call the api  on behalf of grant mark  it's interesting concept  it is more common for public facing applications not so much common for  enterprise style  applications and you can turn it on alternative based on on the client  uh... that's how to do that with us a constant screen looks like for example  all  yeah and they also said okay you you you're client will not be able to see the  password  at least if it's not  reading keystrokes  the last step  after an arbitrary number of steps in between  you get back the access token delivered back to the client application  uh... the way this works is depends on many per protocol parameters it might be  a form post it might be a get request  uh... typically on uh... when you when you think that request it's on at the  soak after the so-called hash fragment  hash fragments prevent that stuff being sent to another server again so you  want to make sure it stays in your client application  uh... and so on  as an example of that  uh...  let's use this one  the chava script  client here  by say hey give me an access token  this triggers the authentication process  i'm authenticating uh... bob and bob  every system should have a bob  uh...  constant screen  yeah give give me that token  and here it is  so that's the implicit flow that is the by far the most common flow and you are  you've done that many many hundred times they are typically when you download an  application from the app store  you authenticate  you might not see that it's a browser behind the scenes big if they are clever  and style the webpage exactly like the surrounding native app you might not even  see that yeah  but it's typically a browser window going going up going to the server  and letting the server do whatever is necessary to do  give you back a token  so that's the implicit flow  and again that there are many many more options that uh... the intention of this  talk is what to give you like pointers where you want to  follow up  on on on the details because obviously there's you know  i could talk many days about that  the next pattern which is enabled  implicit flow  is federation or social logins or you know enterprise logins yeah  again the client application using the implicit flow model it hands off control  to the server  now how the server  authenticates the user  is totally up to the server  the only thing that you know the client wants is it is an access token in the end  okay  so i am we've briefly seen that so when i do a log out here  and come back to my  uh... application  and do uh... access token  you see here  uh... i i i have options here yeah i'm dead as a local login  that there are external logins so you know uh...  if if this  authorization service configured to allow external logins for this application  then then it can give the user more options here so maybe maybe i want to  connect to my enterprise  uh... authentication thing so i can use a dfs maybe i wanna  support you know  uh...  social logins  or maybe i want to do you know cloud stuff whatever  so let's let's let's press google  same constant screen  again declined application doesn't know the difference as long as it gets a  token  that will be valid for the for the  api  next one  i'm doing in time  that is now one of the  the most interesting ones i think yeah so that the first part was mechanics a lot  you know like okay  that this flow that this flow that this flow  once you  you know cut the hang off of these flows  you will at some point said okay  how long should this talk would be valid for  and basically  we have a couple of not see it at that that we can turn based on what type of  application you're writing as a  uh...  there's obviously that the style of application where you want to use that to  log in once and then he will never be bothered again  in his whole lifetime with a log in dialogue  so i i just recently got uh... the answer on the issue track i think  what's your maximum  lifetime for tokens  and i think it's in dot max value does that work for you  it is that's that's fine  i mean it it's second but it's still a couple of decades i think uh... so  that that should work  other other customers want to write applications where the user should  periodically log in  maybe once a week once a day maybe it is so you know  sensitive that you know you want made one make sure that that he has to re-authenticate  a uh...  multiple times  so  there are two not state that you can turn to find you in this behavior  the first the first one is the access token lifetime itself yeah basically  meaning  the short of the access token lifetime is the more often the client has to go  back to the server get a new one  and yet i want is that  said the single sign-on session the user has with the  server with the authorization server meaning the short at this session is the  more often you will see a login screen  so basically on on one end how often do i need tokens on the other end how often  do i need login screens  i give you google as an example  they do  uh... a single sign-on cookie for fourteen days so you only have to  re-authenticate with them every two weeks  but the access tokens are by default just one hour  okay so the client application has to get a new access token every hour  but only will show the login page every fourteen days  well so that's like they are trade-off and actually they did they made some  research  that uh...  it's more secure to not show the login page as often  because then you just get used to typing in their password in everything that  looks like a password box  and if you educate them that this shouldn't happen that often  then they are more  cautious about it  same goes by the way for password change policies it's it's uh... that there's  some research saying  if you choose one really good password it will be better than the one you have to  pick every forty days in your company for example  so  oh yeah and cookies have sliding expiration as well which tokens typically  don't have tokens have a fixed lifetime  and actually proc  directly after this talk proc will show  a client library we've been working on  which can automate much of these  renewal of tokens so there's a really interesting technique for  chava script basically when you say that okay  the token is valid for one hour but the cookie is valid for fourteen days  where and then you can write some code that monitors the lifetime of the token  and when it comes to the end like sixty seconds before  the end of the of the token lifetime you can open an invisible eye frame  going back to the token service getting a new token and replacing the new one  with the old one  and as long as there's no login prompt  this will work  and we've written such a library inspired by the way how google does it  they do it exactly like that  and proc will show you that after  this session  now there's an interesting technique which many people don't know about  which  gives you better control over token lifetime  and it's called reference token so i've just shown you  the chasing that token right so it's a chasing data structure  you  you know you see let you sign it as a lifetime on it yeah  uh... and you ship it  chasing that tokens are very hard to revoke  before their lifetime and  so let's say for example you lose you losing your phone for example and  you want to go to a website maybe say like you know real big red button i lost  my phone please invalidate all my access tokens here  it's hard to do with chasing that tokens because you know  that they're self-contained as long as they are out there they're good  you get much more flexibility actually when you don't ship  these data structures yes so the idea with reference tokens is that you keep  the actual data structure on the authorization server  but only ship a handle  to that token  basically  you will ship that handle back uh... from that token the client will send the  handle  to the service to the api  and the api will do a back channel communication back to the authorization  service saying that is this handle valid  if yes  give me the content of the token  and and from a from a  application point of view  this doesn't make any difference it's it's just a different way how to validate  the token  which means  that now you can provide a  programmatic ways and self service ways to revoke the tokens before they expire  okay  for these customers or people that that that want to have basically tokens that  live forever  that is a nice middle ground here you can issue a really long-lived token  but have the ability to revoke it at any point in time  so that is often you know  the answer to the question  i'm writing a mobile application  i want you know it uses the site to look in once  but i want to have protection whenever the talk that the phone gets lost or you  know  things like that  for example what uh...  microsoft is doing is whenever you change your passport in asia active  directory they invalidate their tokens which i think is a little harsh to be  honest  uh...  i would have  maybe expected like resetting the passport would trigger that  uh...  anyways we have in in in identity so that we have both uh...  a product programmatic way of doing that as death and revocation endpoint that  you can call  or desert self service portal where the user can revoke tokens and i will show  you both in a second  actually wish you both now  makes much more sense  so yeah  let let me show you a different client and that that's more mostly like a proof  of concept how to write a native client there  so that's not a browser  yeah  uh...  but if i  uh...  get it  one when i get a token  i basically open an embedded browser like  a web view  freaks me out  and then i you know authenticate somehow did the idea is the same decline  doesn't want to know how that works here we just you know get getting called back  with a token  hello google  uh... here we are you see he has the access token and that looks pretty big  so that must be a jason lep token yeah  uh...  if i hope sorry if i go to my configuration for this client in identity  server  and said the  access token type to  reference  and make the same thing again  access token  google  you see now  this talk is much smaller  so when i now call the service  you know it works  but now at the same time the user can go  let's say to to their self service portal hdps  which is a local host  of course  application permissions you know sign in  and then say hey i lost my phone  and now i call the service again  unauthorized  but that's that that's a nice in between  way of dealing with long-lived tokens i think  when you ask certain industry experts  or other companies that produce token services like in asia for example  that the answer is often  it's called refresh token  refresh token is the is the default answer and there's a thing called  refresh tokens in  in the specification of all of  but i don't think i really don't think that this is a good fit for mobile  net applications  basically  i'll show you what  the way this works is that you are adding a special scope to it called offline access  and when you when you said offline access you get back a special token called  the refresh token and this refresh token can be used to  get new access tokens for a very long time  without having the user being involved again  so the way this works is we say hey give me a give me this offline access thing  this time you can't  uh... you can't uh...  get the token directly you have to say give me a so-called authorization  code  that will basically mean you get back uh... a code  and then the the the application must do a back channel communication to the  authorization so i say hey  it's me here's my id here's my secret  and here's my code  okay and you will get back  an access token and the refresh token  now  using this technique on on client applications mobile devices implies that  you ship your client secret  to the mobile device  does that make any sense  it is called a secret right  okay  um... and you get back in return a refresh token which is a very very very  long-lived token  and with this refresh token you can get new access tokens  so what is what what makes this better  than having just long-lived reference tokens that you can revoke anytime  where this thing was designed for  originally is for server side applications  so when you are in the data center and let's say you're having this  dispatch job  um... running every  every thirty days that that wakes up  needs to access data of the user on behalf of the user and do some  calculation  you know write something to a database go to sleep again  you wanna make sure that never ever  uh... this dispatch job  uh... is missing the token it needs to access the data of the user  okay so you need like a way to get to have long-lived tokens  then this is a nice approach and so basically you store  the access token in the back end you store the refresh token in the back end  and you store your client id and client secret in the back end  and then you can get new tokens whenever you need to  but having at the same time the option to revoke access again to your data  by removing the refresh token from from from the database  when you hear refresh tokens as the answer to your long-lived token problem  uh... i wouldn't  i wouldn't immediately believe that  refresh tokens are for servers  they are good for servers that's where they were designed for  in my opinion  long-lived reference tokens are much more suitable for  the client side of applications where you wanna have this long-lived semantics  and don't have to re-authenticate the user  if you want to have something in between like google does you know then then play  with the two  nobs yeah that that i that that i told you like sir cookie lifetime access token  lifetime and find the right  the right you know balance  in between that that works for you  the red the red the revocation endpoint i i am  uh... mentioned that and all your i can show you a sample of the the refresh  token thing as well  uh...  so that's a  a server side application as i said that's where i think it it it it it fits  the best  uh...  so when i don't  request the offline access scope you know i'm doing this the standard flow  here  that's just google again  but type typing in bob is actually faster  i get my my code  code here  i get the token  and i have my stuff right  uh... he has an access token in in that case it's a reference token but that's  just coincidence yeah  but if i now add to the uh... offline offline access  scope to it  say okay  now you see that  on the constant screen  we always trigger the constant screen  uh... if enabled for offline access because it's such a highly privileged  thing to request from you  even if you say remember my decision  you will get this to see the content screen again  get the code  get the token and now you see here  just now  the refresh token  and now you can go to the application you know and then  we have our claims here he has the access token he has the expires ad  and here's my refresh token and at any point in time now  the server can say refresh the token  which will give you a new access token  a new refresh token  when you watch here the lifetime  you will basically renew the lifetime  into the future  and if you don't want it anymore  you can say  revoke the refresh token  and when you then refresh the token  you get an error  it's gone  that is how it looks like in dropbox  they call it  my apps but it is really refresh token management under the covers how do you  get rid of long-lived access tokens  and that's it  we have time for questions  uh... thank you very much so far  there's the slide x are here  and if you have any questions  feel free to ask them now otherwise  enjoy the rest of the conference thank you  and get stickers  if you want them  questions  happy  despy as a
Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_0_1727.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_1728_2339.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_2340_6539.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_6540_10175.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_10176_12203.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_12204_19499.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_19500_19763.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_19764_19811.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_19812_20051.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20052_20099.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20100_20219.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20220_20447.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20448_20603.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20604_20675.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20676_20747.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_20748_21239.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_21240_21983.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_21984_22043.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_22044_22607.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_22608_25151.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_25152_25415.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_25416_25547.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_25548_27719.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_27720_27899.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_27900_27947.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_27948_28475.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_28476_29159.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_29160_30287.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_30288_30395.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_30396_32723.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_32724_37835.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_37836_40163.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_40164_44711.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_44712_47543.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_47544_47771.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_47772_49559.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_49560_49883.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_49884_50723.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_50724_51047.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_51048_51503.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_51504_51551.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_51552_51635.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_51636_52391.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_52392_52787.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_52788_53447.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_53448_54791.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_54792_55115.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_55116_65771.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_65772_65843.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_65844_65975.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_65976_66827.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_66828_66923.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_66924_66971.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_66972_67019.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67020_67067.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67068_67391.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67392_67763.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67764_67811.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67812_67907.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67908_67955.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_67956_68015.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_68016_68615.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_68616_68819.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_68820_68867.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_68868_70511.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_70512_74591.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_74592_75551.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_75552_75635.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_75636_75875.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_75876_76163.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_76164_76475.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_76476_76583.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_76584_76751.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_76752_77543.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_77544_77711.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_77712_78527.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_78528_78995.png Securing_Web_APIs_____Patterns___Anti-Patterns_-_Dominick_Baier_78996_79332.png