Introduction to OAuth 2.0 and OpenID Connect By Philippe De Ryck

[Music] all right good afternoon everyone I hope you enjoyed lunch and welcome back for the afternoon session I'm going to be talking about o out and open ID connect so um we have three hours um I have a timer in front it says 180 minutes uh that doesn't happen too often for conference talks or conference presentations so we're going to have a pretty interesting journey into the landscape into the world of O and IDC so uh sit back relax which is also not something that happens that often at conferences uh so enjoy the environment um sit back and relax and I'm going to take you on a hopefully wonderful journey into o out and oi DC all right so what are we going to talk about o out o out is well it's it's confusing that's certainly one thing it's called the authorization framework um I'm not really sure that was the best description of what o is is but what really matters is here that oout 2.0 is from 2012 that is a long long time ago that is 11 years to date so that's definitely not something recent and as a consequence things have evolved and we've had some additions we had retractions we had um changes modified behavior and so on and so on and what we basically have today is a whole bunch of specifications we have o IDC on top of O out and in general it is a massive uh massive ly complicated topic which is essentially why I'm here and if you're looking like this right now obligatory cat picture for the presentation if you're looking like this you're definitely not alone I've been doing oad and IDC work for a long time now um multiple years and I've seen how much developers struggle with it I've seen developers face choices that they don't really have an idea of how to make them and so on and so on and I'm not alone in that and there there's some effort going on to build an O 2.1 um which is basically not a new mechanism it's the old one but kind of all the best practices rolled into one specification so instead of having to read like a dozen specs or more you can read one spec and be up to date so that's already a big Improvement but o 2.1 is not there yet it's going to take a while um because there's some dependencies that need to be fleshed out first before we get there but in this presentation I'm going to be talking about o or o 2.0 or 2.x or whatever and in in essence that kind of means the best practices for o 2.0 which will eventually become 2.1 and which is essentially the current version of oot if you want to look further down the line I don't have slides on that because it's future music but they're working on like a successor of oout which will not be oout 3.0 but probably something called gnap uh the grant negotiation and authorization protocol which is kind of a very much more advanced version of oart um from Lessons Learned and so on but that is definitely future music that's being actively developed so that's a couple of years out before we talk about that so instead of looking to the Future and looking at great things that will come down the line first um let's do what I mainly focus on and that's helping you understand what the best practices are for building o out applications today and to do that I'm going to use a whole bunch of slides a whole bunch of pictures I'll use some examples uh some demos uh as well so you get to see something in action some online will have a break as well because 3 hours is not a good idea to keep talking in one straight piece and hopefully by the end you'll walk away with a solid understanding of what these things are what you're supposed to do and where you can look for further knowledge on this topic what is O out really about and how does oidc come into play and I should be careful here usually I'm used to walking around but I I guess the cameraman is not going to like that very much if I'll be walking around so I I'll try to stay in this area uh while moving a bit but what is O and IDC really about well well it's about clients client applications trying to do something and a client can be any kind of application can be a backend web app can be a front-end web app a mobile app even just some piece of software running somewhere without really being a specific type of client but clients are trying to do something and they rely on a central service to do that and I've rephrased this slide in like human understandable questions and one of the questions that a client can ask is like hey can you authenticate this user for me I have a user here and I want to know who they are can you make that happen for me that would be openconnect and a second question is like hey I would like to access something probably on behalf of the user or directly like an API can you make that happen can you give me something I can present to the API so that the API knows who I am and can make an authorization decision and that part is O out and how these things relate to each other will become clear in short shortly of course if you try to access something it's there's some resource that you want to access and in general um use cases today that's going to be an API we're building API based applications I would say the majority of use cases for oout will be an API you can have other types of resources that might be accessed but in general we're talking about apis these days so the client is asking the API like hey I want to do something can you make that happen and the authorization part or the relaying information there that's going to be an O out aspect and then API if you're an API you get a call you're like how do how the hell do I know if this is uh allowed or not so there's going to be some dependency on that Central service to figure out if this is allowed yes or no and that can be very explicit like a request and a response or very implicit like validating some data and making sure it's valid we'll talk about all of that later on all right this triangle is important that's the landscape of what we're going to talk about the majority of the complexity is in let me highlight this where's my screen here is in this connection it's a single Arrow here when we we get to the meaty part of the presentation um it's going to be like 13 steps or something to get that done so it's it's slightly complicated but once you get it it makes sense hopefully and you can move forward from that if you've been dealing with o out or oidc you may be a bit skeptical about the terms I'm using here like a security token service you won't find that word in the specification somewhere but you'll find authorization servers when you read o documents or identity providers when you read IDC documents and this kind of means that I would have to switch between two terms throughout the presentation depending on what we're talking about and it gets really confusing if you're talking about things at the same time because then what term do you use so what I do in in this session and in all my training courses basically is I try to settle on a single set of terminology some simplifications to make things understandable and if you want to read the documents or translate this back to what you read in rfc's uh this slide can help you so for o out we talk about resource owners which is like a very generic concept but in general in most applications we build that's going to be a user and we talk about resource servers which is like I said apis in most of the use cases we have today and then we have the authorization server which is that security token service and then we have client applications which is the client trying to do something and that's what I'm going to use throughout this presentation before we dive in a small word about myself I'm Philip D I'm from Belgium so this is kind of a a home presentation for me which is nice for one and I basically help developers and Architects software professionals understand security that's what I do I have a PhD in web security and I've been doing security for forever basically and what I try to help teams is understand security make decisions make trade-offs um Implement best practices and so on and I do that through security training conference talks online courses and very specific Consulting on Advanced topics like o IDC and so on I'm a Google developer expert and an alzer ambassador these are defal Outreach programs um where they reward people contributing to the community with conference talks and sessions like this so uh that's definitely an honor to be part of those programs and I also organize seab Dev which is a Belgian security course where we invite people from all over the world uh to Loven in Belgium to speak about security it's a onewe course and if you're interested in that it runs in June next year so check it out if you want to for this presentation I have some slides um you can grab a copy from my website so I'm very easy to find um if you Google me you'll find that you'll find the slides and so on and so on you can download the PDF later or you can grab it right now if you want to or find the link on LinkedIn or madon as well so that's an easy way to get a hold of those slides all right let's dive in let's talk about use cases let's talk about flows and let's talk about doing something with o out and with open ID connect so let me go back to this triangle um where we have o out and open ID connect whether it's O 2.0 2.1 whatever 2.x uh that's the easy way to describe that and I want to focus I want to start with open ID connect because open ID connect is the easy part well the the interaction with that security token service is complicated but the concept of what you're trying to do only involves involves two parties we're trying to authenticate a user what does that look like well if you're building an application today if you're starting from scratch I would say you don't Implement authentication anymore you don't want to deal with usernames and passwords and password reset features or passwordless or pass keys and web authentication it's an absolute freaking nightmare and if you involve multiactor authentication that's a lot of developer effort so if you want to build an application today my recommendation is going to be let's use an identity provider let's use that security token service and your your application just asks the service like yeah you tell me who the user is you handle authentication and I'm I can focus on what I do best and that's that's building the application that is one use case where we offload authentication to a central provider and that can be very commonly um scenarios involve um Azure active directory you just offload authentication to Azure they handle everything they handle multiactor out and your app just gets information like hey this user is Philip and this ID is something something and whatever else you need to know or want to know about that user done your application basically zero lines of authentication code and that is a very nice way moving forward that's one use case other use cases involve social login for to implement sign in with Google you're going to be using open ID connect to make that happen to talk to Google and Google is going to come back to your apps and say oh yeah we know this user as Philip and their Google ID is 17 and so on and so on that's essentially how that works I know it says connect with Facebook on the slide here um that's a complicated story because Facebook does not do open ID connect but the concept is they call it Facebook connect so I'll I'll leave it in the middle it's you make up your mind about that and then the third use case that's very very common in the Enterprise world is doing SAS authentication so basically if you're um if you're building software if you're building a s if you have Enterprise customers they're going to come to you and say like yeah we don't want to make users on your platform we just want you to call us and we'll handle authentication of our users and you make sure that works and that used to be Sul back in the day and today uh you'll Implement that with open ID connect or Su if you're very unlucky and fortunate and you have to implement that as well but you can bridge saml and IDC together and so on and so on but that's essentially what open ID connect doeses in practice all right I promised you some demos let me show you um briefly what this looks like just so we have an idea um of what's going on and then we can refer back to these examples later on all right live demo so um things are going to go wrong and I'll deal with that as we move forward all right what I have here is I have a very crappy demo so my demos really suck by the way so my apologies for that I have a very crappy demo where we have a backend node application where we're going to use open connect to authenticate so if we look at the demo right here like I said it it's crap but uh bear with me please uh we're not logged in this is anonymous now we can click the login link it's not even a button it's just a link we can click the login link and that will uh run an oidc flow where we have to authenticate and that's the offloading of authentication so if we click this we'll be taken to our identity well we were sorry sorry about that if you click this we'll be taken to our identity provider where we are asked to log in I'm using OD zero here as an example by the way because I am an alzero ambassador and it kind of makes sense and it's easy to show uh you can do this with any implementation you can do this with keycloak used very often with Azure active directory you can run your own software like identity server or whatever you prefer doing as long as you have an oidc implementation you can run a flow like this and this basically handles authentication at the IDP level so I can log in with my username and password and when we do that we're sent back to the application which now says like hey hi Philip and so on and so on so that's open ID connect that's how we integrate that into an application what happens in the back end I'll show you that later in the presentation when we talk about the details so that's oidc in practice all right use case number one by the way I have a lot of slides with a massive amount of text on that so if you ever followed like a PowerPoint course step number one or lesson one is like you only put seven words on a slide and otherwise it's crap and go home the reason I do that is because I shared you a link to the slides and if I have a slide Deck with all pretty pictures that's going to be very nice for you to look at here in the room and then next week when you revisit revisit the slides it's going to be like yeah I have no idea what he said so maybe you can find a recording somewhere and if you scroll through like three hours of video to find that exact thing I said so yes I have a lot of slides with text I skip over most of the text in the U in the Talk itself but you can refer back to that later on uh when you download the PDF so use case number one only using oidc there's no o out involved it's just an application asking who is the user gets some information about the user and handles the authentication with that information that's it very simple very straightforward and actually the def facto way to implement authentication in new applications today you really shouldn't be implementing usernames passwords reset and so on you should rely on that Central service to do that all right use case number two only using o out when you when you're when you're only using o out we don't really care who the user is because we already know who the user is to us and a scenario like that would uh for example and let me go back to the triangle here that's the full picture that we talked about in the beginning o out um would be this part of the triangle which is most of it but it's a client let's imagine you're logged into a client application and you want to connect that client to a second backend application that's what you can do with oot and one example I often use is buffer a social media scheduling tool so I very often schedule social media posts up front because I don't want to be doing that live in the moment and I have connected buffer which is its own application where I log in as my buffer my buffer user and so on I've connected that to my LinkedIn account and to my masteron account and that's basically how the application uses o out gets necessary tokens so they can talk to LinkedIn whenever something needs to be posted and get that post out that's one example of how to do that I'm going to use a second example here in the demo and I'm in my training applications I use food-based applications I use restor grade with restaurant reviews because I like good food and great restaurants so that's a nice win and I use a second application called virtual foodie which offers services to Foodies and whatever ever and we're going to integrate these two in a scenario where you can basically um use o to talk to each other so let me show you how that works all right I have to start a couple of things here so we have one API well one application running that's the virtual foodie application and we have one API running and that's the restor grade API so two separate applications imagine these are two different parties when you run this in an online scenario all right so if you go to the application it looks like this I put a little bit more effort in this demo because otherwise you would it would make no sense at all what we have here is we have SIMPLE login the thing I said you should never Implement yourself they handle login with their own users um login log out stuff like that very simple very straightforward um that's essentially how the application works and if you look at the code you will see that this is a fully independent application so the application here has a bu buom a whole bunch of moving Parts but we have a list of users implemented very crappily I fully agree with that we have a username a password and so on and so on and that is what the application does you just log in you're authenticated like I would do with buffer the online uh the social media scheduling tool you just log in with an account and that's it and we're going to connect this to restor grade and restor grade is its own application it's an API which has review information it has its own users it has its own uh set of uh restaurants a set of reviews and so on and so on and what we're basically going to do is we're going to connect those two applications together and to do that virtual foodie our website that I've shown here in the browser needs a token so it can call the restor grade API so it can get reviews for whatever user is being connected that's what we're trying to do with o out here and if I click this button connect to restro the application is going to run an oout flow to make that happen it's going to run a flow which will result in asking uh for tokens and make sure that that happens um and before I do that let me let me sure we can log out so I can show you the full flow in action all right so if I click this button the application is going to start another flow in O out flow this time which ends up back here because to do that restor grade has to know who I am so it can give tokens so that the API the application virtual Foody can access the API on my behalf so if I log in here with that user I have to provide consent this is a thirdparty scenario we're basically giving a thirdparty application access to my data stored in the restor grade application so it's like hey do you want this application to read your reviews and I'm like yeah that's fine and off we go so now we're connected nothing happens so far but now we can start making API calls so I can click this button which means that in the back end there's going to be an API call to restorate fetches my reviews my list of reviews apparently I have four reviews in an application and my favorite restaurant style is meat restaurants and that's based on the data that you can see here so my reviews in the restorate realm are located right here we have four um they're associated with restaurants and based on the reviews you can kind of see that the restaurant style definitely makes sense so um that's essentially what's going on right there that is how these things are linked together and how that token connection works that's oart there's no user authentication involved yes there was one in the step in the flow but this application virtual Foody doesn't really learn who I am all it gets is a token and if you look at the output of these applications right here you can see that um the restr API is receiving some calls to look up reviews for user with ID something something that's the user ID for that user on restorate and that is mapped to reviews and based B on that they know which reviews to collect all right did I mention that o is somewhat complicated well there we go all right this scenario only uses oot you'll find this in a lot of various scenarios for example buffer and Linkedin social media scheduling you'll find this whenever ANC is asking uh Google for permission to access your calendar that's an O out flow some application somewhere is asking like Zoom is asking permission to integrate with your Google calendar so they can read your events they can schedule events and they can add links to events and so on that's an O outflow Zoom is the client Google is that security token service Google has a calendar API and that's how these things work and once you start watching this pattern you'll find it literally everywhere especially when you see that consent dialogue pop up asking you hey do you want to allow this application to access that that's definitely an O outflow happening right there there's a third scenario and that third scenario is where or third use case is where we combine the first two in one flow because open ID connect basically uses the flows from o out for a different purpose and you can combine the two together so you can handle something a mobile app would be a good example so the restor grade mobile app where you can do your restaurant reviews and look up restaurants that app could ask the STS like who is the user and by the way once you've told me who the user is I also want to token so I can access some apis to fetch reviews and so on and so on that would be combining the two together in one flow where you can obtain user information and obtain that access token so you need can access the apis that's essentially how these things are used in practice it's all about tokens so a client needs tokens it needs an identity token to figure out who the user is it needs an access token to access an API maybe there's a refresh token involved for like long-term AIS and so on and so on we'll talk about all of that by the way no worries that's essentially what we need tokens and we get those tokens by running a flow or a grant in O terminology like there's a whole bunch of flows or a whole bunch of GRS that you can use all different configurations for different use cases and it's up to you to select the right one and if you look at the specs um especially throughout the year since 2012 there's like a whole bunch of these flows and it's like you have you have the implicit flow the resource owner pass credentials flow or grand the hybrid flow and so on and so on it's like an absolute mess trust me it's pretty complicated especially because some of these are deprecated some of these are like still valid but no longer used because it's less practical than others and you end up with like a a very complicated selection process especially when you have Legacy or Tech dep lying around with old flows and like yeah what do we do now and how do we handle this the good news is things are being simplified at a rapid Pace especially the last three years we scrapped a bunch of these things and very common today use the authorization code flow and decline credentials flow these two are very very common in a lot of scenarios and I'm sure if you've ever dealt with oot or oidc you've used one of these flows in practice the other ones um apart from the deprecated ones are still valid and are for specific use cases I'm going to focus on these two in this presentation right here all right and by the way you'll find some custom flows as well which we're not even going to talk about remotely here let's talk about the alization code flow the one flow you should remember the one compli the second flow the client credentials flow is like super easy so if you understand this one you're done basically for this presentation which is which is which is good so 5 minutes of effort and then you can relax for the rest of the session so how does the authorization code flow work and that's where all the steps come into play and where that one Arrow the the one from the bottom to the top becomes like super complicated let me walk you through the scenario I showed you before um where the user is clicking like a login button or a connect button we're doing it generically now and we're walking through the flow what really happened in that demo I showed you before well the first thing is the user does something to trigger the flow like click the login button or click the connect to restorate button something that tells the back end in this case like hey it's time to run an oout or oidc flow run an authorization code flow make that happen please and that means that the back end is like okay if I want to run a flow I have to send the flow to the security token service so it's going to redirect the browser um to make sure that the browser sends a request the authorization request we call that to ini initialize a flow and the browser is going to follow that redirect which results in request number three on top so that's a redirect happening where the browser goes to that security token service in the demos you saw a login form that security token service receives a request it's like hey I would like to know who the user is and the security token Service is like I don't know who the user is Bam login form like hey who are you that's why the user is involved in that flow that's why the flow goes through the browser so we have user interaction whenever we need it and the user is like oh yeah I'm philli and my password is fluffy dog 17 exclamation mark That's not my real password by the way this is just a PowerPoint example so don't try it on my accounts I don't want to get like mails of just leave it alone it's fine it's a secure password but it's not my real password so we can talk about that later so I'm logging into that security token service and when that happens security token service knows exactly who I am if you sign in with Google Google would ask you hey you want to log into your Google account and then Google knows exactly who you are and when we have done that we send a something back to the client application at the bottom and to send something back the only way we can do that reliably is through the users's browser so we send the browser another redirect in Step six and we tell the browser like you go back to the application and when you do follow this URL and in the URL there's a query parameter and in that query parameter there's an authorization code hence the name of the grant or the flow authorization code flow and that authorization code browser is like yeah I'll follow the redirect and the request goes back to that back end we call that the call back or the return uh endpoint and that back end gets a request reads the query parameters and now has an authorization code and guess what that authorization code means nothing it's just a temporary value that only means something to the security token service this one so the backend application goes goes back there and it's like hey I got this authorization code from the browser in Step seven in this case what does that mean by the way I am the restate backend or the virtual foodie application and I would like to get some tokens for this code and the security token service will validate all of those parameters like oh yeah I gave this code for Philip like two minutes ago or two seconds ago that's perfectly fine and it provides the client application at the bottom with tokens like I said generic uh I'll talk about spe specific tokens in a second and then the backend handles those tokens and we have completed the authorization code flow so here we have 10 steps for that one single arrow in the Triangle like the client who is the user bam 10 steps to get that done but once you understand the interactions these steps are not that complicated this flow is generic for a reason because it supports both o and IDC scenarios depending on how you configure the different steps in that flow I'm going to talk about that in a second that that's what kind of flow we are running so let's talk about this flow for IDC what do we want to achieve with IDC I only just noticed a live captioning that's awesome all right life is with a V by the way sorry about that bad AI yeah this is not going to end well if I disappear during the break yeah please come find me all right um so what does this mean for oidc open ID connect is about user authentication so it means that the user is doing something which involves authentication so the interaction that triggers a flow is typically clicking a login button sign in with Google log in with your Azure active directory or whatever that's the interaction pattern the the semantics of this flow and then the rest is kind of the same we send the the redirect to the browser browser follows that to the STS we authenticate to the SDS with the same username and password as before and we get that authorization code it's an authorization code flow the authorization code goes back to the browser or to the S through the browser back to the backend application in Step seven so we can exchange it for tokens in Step eight and then step nine is different or different no step nine is specific now because in Step nine we receive an identity token and that is a very precisely defined token in the oidc specification that says like at the end of an oidc authorization code flow you get this token and that token contains these claims with some meaning and so on and so on that's how you run an authorization code flow for open ID connect all right and then of course we can handle that token um to authenticate the user so what does this look like in specifics if you want to see an actual request I have that information on the slides as well so the request in step two and three is the authorization request that's the official name it's basically the start of a flow and that contains a whole bunch of parameters you may have seen these in the past it's like a very long URL with a bunch of parameters configuring the exact flow the response type is code that means we expect an autorization code at the end of this uh interaction we Define an open ID connect that means you add scope equals open ID that indicates to the STS here I expect an identity token at the end of the code exchange that's how you can recognize an oidc flow there's going to be scope equals open ID mandatory no question about it the other ones are optional profile and email are signals to this SDS saying like hey I would like to get some email information about user and also include some profile information if you have it that's how if you sign in with Google to an app how they get your profile picture that you have in Google that's uh Google sending that based uh on this flow in that identity token we also tell up front which client we are so every client that wants to run a flow with STS has to be registered with some configuration parameters and so on and so on and here you indicate what client you are because this is an ID you have received before and that's essentially how you make that happen the next value redirect U on line five that's essentially the end point for step seven where do you want to receive that code you can Define multiple endpoints and you have to specify one of your predefined endpoints in this step you have to say like hey I know you have a list of potential endpoints or sometimes just one when you're done send it to this specific endpoint please and then line six and seven I'm going to skip these for now I'll explain them in fiveish minutes so let me skip those security features all right all right that's how you start a flow and then step three uh well four and five the user authentication that one is not defined anywhere oidc is all about user authentication and then in the spec it says somewhere like how you actually authenticate user your problem not ours that's you problem you figure that out whatever you think is fair you can ask for a password you can do a web authentication pass Keys passwordless magic links whatever works for you basically but once you have figure out who the user is that's when the protocol comes back into play the flow and that's step six and seven that's sending the control back to the application what do we have here on line one we have that call back we provided in the beginning we said like when you're done send the code here bam that's that endpoint and then we have a query parameter code equals something something and that's the authorization code that meaningless value all right at this point that code ends up in our backend web application which which is going to exchange it for tokens in Step eight and that request looks like this it's a post request server to server in this case a back Channel request where we indicate that we're trying to exchange an authorization code we we uh identify ourselves as a client so we're client with this ID and we authenticate as that client this is a confidential client meaning it has a secret like a client password to present there might be some key based authentication going on here we're not going to talk about that here today but the client authenticates that's a very important security measure client authenticates we inform the SDS where we receive that authorization code a call of course we provide the authorization code itself and then line nine I'm going to skip that until later and the response in Step nine is adjacent response ID token the identity token and that identity token is a jwd Json web token and contains information about the authenticated user and that's the end of the flow the application can now open the token up read the payload which is a bunch of claims of what you basically asked and one of these claims is mandatory one of these claims is called Su because the people that wrote the jpec have a fetish for three-letter abbreviations seriously read a spec I when I talk about jots in my training courses I have a game like jot three-letter abbreviation Bingo where you people have to guess what these things mean and some of them are easy and then gets really complicated like I have no idea what CNF means and stuff like that but the sub claim the sub is a user identifier that's the unique ID of the user that authenticated the user here Philip within the STS so if you run this flow against your Azure active directory your user in Azure Ed has a unique ID that will only ever be used for your account never reused never duplicated so whenever the client application re receives an identity token and sees that ID it knows like hey I know who that is it's the user with this ID and internally we know him as Phillip okay makes sense and that's how authentication really works and if you run this with Google sign in with Google and you run this today you'll get an identity token with your Google ID as a subject you run it in five months you'll get the same Google ID in a subject and that Google ID will always be associated with your account that's essentially how this works in practice all right let's see that in action well I would like to show you that in my demo application you know the one that wasn't very pretty but to be honest it's not very interesting to show you that in a demo app because it's like you see a redirect and then the app does some server to server communication that we can't really observe and then poof there's an identity token it there's not much to show so what I'm going to do is I'm going to show you the different steps of the flow in like a simulator and I'm going to show you a little bit of application code right here you can see that our users listed in this application have that ID that you recognized from before so they have an ID that is known by the STS so whenever this the identity token comes back with a subject claim that is essentially how we can figure that out another thing you can observe is I'm using a library Express open ID connect this is nodejs express code and that Library does all of heavy lifting as in I don't have to do anything basically I just tell the library handle oidc flows for me and make sure it happens and off we go so if you would look at the actual implementation we provide it with a bunch of configuration parameters like a client ID and a client secret and the Scopes that we would like and that we run an authorization code flow here and then everything else just magically happens which is pretty awesome as a developer pretty useless if you want to do a demo so uh brings me to step number two I've been doing a lot of demos on this and one of the one one tool I built is called a flow simulator and a flow simulator is intended to show you the steps of the flow to visualize them in like a fake environment so we're not really doing this as a backend web app this is a front end web app running in a browser but it will show you the different steps so what we can do here is we can configure our SDS which is running on ss. rest.com that's my demo uh implementation and we can pretend to be a backend client application you can see that we have that client secret that I showed you before right here in the browser which is a very bad idea so if you ever want to do this yourself this is a public tool you can do it yourself but please do not store production Secrets uh in your browser because well SEC obvious security reasons we want to run an authorization code flow and I want to show you exactly what's going on so in this authorization code flow you can see four steps that's essentially the things I showed you on the slides as well we have the initialization that's basically sending the control to the SDS we have the redirect back we have the code that comes in that we exchange for tokens and then we have the actual tokens um let me also log out um so I can actually show you the different steps we'll talk about why we need to look out in a second all right so initialization of the flow you can see the URL I showed you before right here at the bottom that's that very long URL where you can recognize a bunch of values as well you can see the scope open ID and email we can add profile here as well um and that's essentially how we start the flow so if I do this the flow will go to that SDS that's the SDS asking like hey who are you and I'm going to be like yeah I'm Phillip and fluffy dog 17 exclamation mark um and so on and so on and I'm going to log in right here and when I do the FL flow goes back to that callback endpoint which in this case takes us back to the flow simulator and you can see that this is where the authorization code comes in so we got a response that says code is some very long random string whatever all right Next Step exchange that code for tokens so what do we do here we send a post request you can see the request at the bottom a post request to this ss. rest.com Grand type is authorization code client ID client secret and so on and so on all the values are there including the code that we received in the previous request and if we exchange this for tokens then always happy when this works we get a response with the identity token that's a relevant one um and the identity token looks like this it's a Json web token like I said a very long token Let's uh decode it if we drop it in here to decode it you can see the information right here in purple you can see that there's let me highlight stuff um you can see the Su at the bottom the Su claim is this odd zero something something value that's my account at all zero this identifier has never changed in our demos because it's still my account the same account we've been using for all of these uh examples before you can also see email information my email address is right there um no surprises uh there and we can see profile information like a picture and nickname and name and all of that stuff that's there because we asked for profile information that's open ID connect that's the identity token so the application in our back end would open this up extract these claims match that Su to the user with that specific ID and initialize the user's profile that's essentially how we know who that is or if you use sign in with Google you would look up the user with this specific Google ID in your application find their reviews and so on and so on that's open ID connect in action all right and as promised I have a slide with a lot of text about the same thing so mandatory is the open ID scope that's essentially how you signal that this flow is an oidc flow you get an identity token as a response the Su claim is always there the other stuff is optional depends on uh what information is there in the open ID connect specs you'll find two other flows you'll find an implicit flow and a hybrid flow these are not officially deprecated as in they are still valid but they are much more difficult to implement because if you implement these flows you have to do some checks on the client side instead of checks being done by the STS so you have more responsibilities and more places to screw it up if you want to put it blly so the advice today is that we use the authorization code flow that's the current best practice if you want to you have one of these other flows consider upgrading to the authorization code flow it's the current best practice it's the most secure configuration especially when you implement it securely as we'll talk about in the next topic of this presentation all right what about oart well the good news is the flow is the same it's the same authorization code flow just a tiny few differences of based what we are trying to achieve the semantics are different the user is no longer authenticating the user is now connecting an account to an application like connect rest to Virtual foodie connect your Google calendar to zoom we're not authenticating we're connecting accounts that's one difference everything else more or less the same we send that authorization request we go back I'm going to skip through the steps here because well it's the same we authenticate as user if necessary we'll talk about that later we get an authorization code which goes back to the back end which is exchanged for tokens Step n is different now in Step nine we now get an access token no ID identity token but an access token and that access token allows us to access an API so in Step 10 we can now send a request to the restorate API saying like hey get me the reviews for whatever user is associated with this token and the API will get to that the API will use that access token well here API uses the access token here to make authorization decisions in the access token there's going to be a claim Su which contains the user's identifier so the API is going to be like who's the user who is this token associated with gets that user identifier that od0 60 something something value looks up in the list of reviews which reviews are associated with this user and gets that list back to the requesting application that's essentially how this works and we'll talk about how apis do that towards the end of this session if we get there we should all right that's the O outflow what's different well a lot of it is the same um what's different is in this in this slide is line number three so this is the same line number three is different because we don't include that open ID scope anymore because we're not running an open ID flow instead we can use an oout scope and I'll talk about scopes at the end I'm going to ignore that for now everything else is essentially the same all right the response is different as well well the code exchange I haven't shown that that's identical the response is slightly different because we now have an access token which can be a Json web token more on that later and we have an expir in property that signals the lifetime of that access token telling the client like hey this access token is valid for 1 hour up to you to decide what you want to do with that and there's some additional info here as well that is the authorization code flow for oart which is the same as for IDC which is just the authorization code flow all right again slide with text summary um we have run this as I said with a confidential client meaning a client that can authenticate and that means when we exchange that code for tokens as a client we are supposed to authenticate and that's a security measure that's to avoid one of you from seeing that authorization code on my screen here and be like I'm going to really fast write it over and exchange it for tokens and I'm going to be able to steal your tokens because if you try to do that without authenticating as the client it's not going to work and that client secret for authentication is typically stored securely on a server where you can't really access it so even if you would steal an authorization code from somewhere as an attacker you can't directly exchange it because you don't have access to the client secret you can see the client ID that's public info but not the client secret all right authorization code has some additional security measures it's one time use only meaning if you try to or if you exchange it once you can't do it again so even if you find an authorization code later on you can't exchange it not even with the client uh credentials and authorization codes are typically short lift as well that's an additional security measure short lift is open for interpretation ideally that would be like seconds maybe a minute um in reality you'll find authorization codes being valid for half an hour an hour and so on I'm going to leave that in the middle for today usually I ask are there any questions but that's not going to work well in this room um so if you have any questions you can harass me in the break or after the session that is perfectly fine I say harass lovingly by the way so all right if you want more complexity I have that right here for you let's talk about Pixie the authorization code flow relies on an insecure front end Channel which is a very fancy way of saying the browser sucks that's essentially what this comes down to so we're sending this authorization code through the browser and we know that it's insecure because anybody can read it in a browser you as a user can read it you can copy paste stuff into the wrong channels whatever the browser is considered to be not a very secure Channel compared to server to server communication the browser is very insecure and there are some scenarios involving browsers but also mobile apps and so on where the authorization code is subject to attacks and one of these attacks is called an authorization code injection attack which sounds pretty cool but it's horribly complicated I'm going to do my best and explain it uh on a slide so you can actually try to understand what's going on remember when I said that if the attacker steals the authorization code they can't use it that is still true so let's imagine that there's a flow where the user is or the client is running this um for the user and the user um authenticates with Philip and fluffy dog 17 exclamation mark and so on and we get that authorization code and that authorization code goes back to that client application right if the attacker manages to steal that authorization code we're a bit in a bit of trouble and this happens in this case it's a bit weird um because it would require Network level access so it's it's difficult but not impossible browser extensions would be a good way to handle this as well um so it's not impossible but on on mobile apps which we're not really going to talk about much today on mobile apps this can happen more common but the attacker can't really exchange this in this scenario if the attacker would go directly from here to here the security token service would be like Hey where's your client secret if you claim to be the restor grade back end like where's your client secret your T is like I don't have it maybe they can guess but it's not going to work very well trying to guess that client secret however the AER can do something called a code injection and the code injection is basically the attacker taking a URL to the Callback endpoint and inserting a stolen code right there or even inserting their own code in that URL and sending it to a user that's the the the flip side of that scenario basically injecting an an authorization code into a legitimate call back URL and if you give that to the back end the back end is going to be like oo I get a call back on my endpoint and the code is right here and I'm going to exchange that code for tokens and something is going to go wrong either we're going to associate the users tokens with the attacker's account or we're going to associate the attacker tokens with the user account anyway something really bad is happening right here and this attack works this codeing injection works because the back end will authenticate on step seven the back end here is kind of naive didn't implement the proper security measures because there are protections against this in the spec but the back end didn't Implement them correctly which happens more than you want to know and they're exchanging that authorization code mistakenly causing problems codee injection don't break your head about the details they're not very important what you should know is that you need to augment the authorization code flow with Pixie because pixie solves this problem once and for all you know what the best part of Pixie is you are not responsible for checking it all you need to do is use it and that security token service is responsible for checking it which is a that's a win basically all you have to is like yeah yeah handle security and Bam you get security for free or almost for free so what is Pixie and how does it work bear with me this is slightly complicated but we'll we'll get to that what's the concept of Pixie what are we trying to achieve here let me start with that because if you get lost in the details then at least you understand what we're trying to achieve we're trying to assure that we are starting the flow in step two in the same client instance as we're exchanging the code in Step 8 meaning we're trying to preserve the Integrity of the entire flow between step two and8 which are two distinct things one is like the stuff in the insecure frontal in the browser and the other is exchanging a code for tokens and in our attack scenario the attacker was right in the middle they did one in one scenario and then move the value to the second scenario and exchange the code here and what we're going to do with Pixie is we're going to tie these together so that becomes impossible that's the concept of Pixie all right linking the initialization of the flow to the exchange of the code so if you don't remember anything else from pixie that's what it does linking step two to step eight in my slides all right how do we do that by adding some junk into the flows we do that by adding a random or calculating a random value and that random value is called the code verifier but just think of it as your little secret you're the application now or we are the application we're going to run a flow for a user and we're going to calculate our little secret and we're going to keep it for this user specifically like John is going to run a flow and for John we're going to calculate a random value called a code verifier so here's John starting the flow and we're going to calculate that code verifier I'm going to keep it secure I'm going to drop it in John's session cookie for example makes sense or store it in a database associated with John Zan but the cookie is the easiest in practice and now we're going to prove prove to the SDs that we actually know a secret without telling it what a secret is and we do that by calculating the hash of that code verifier and we call that the code challenge because why make it simple when it's so OD we call it the code Challenge and we basically calculate the hash and if you know something about hash functions it's easy to go from data to the hash but it should be hard or impossible to go back from the hash to the data except by brute forcing so if I give you a hash there's no way for you to tell what I used as input for that hash could be one bit of information could be 15 gabt of data up to you to guess and if it's 15 gigabytes good luck guessing that uh that data it's impossible so what we're going to do with that code challenge in step three is we're going to include that in a flow we're going to start the flow in step four which used to be step two and we're going to tell the STDs like we are running a flow here and we have a little secret that we're not going to tell you just yet but here's some proof that we had it because we used it to calculate a value that we can only calculate if we have that value and that's how we initialize the flow and the STS is going to be like okay you claim to have a secret we'll see about that but first we'll do whatever we do we authenticate the user and we send an authorization code back and before we send that authorization code back we're going to store that code in the database as we've always done and now we're going to associate your hash with that authorization code like you said you knew a secret well when you come back later we'll verify that but for now we're good and we get that authorization code which goes back to the back end in Step 10 and our backend application is now going to exchange the code for tokens and in this step it says like hey I got this code and I'm this client and you know what when I asked for this code I proved that I possessed the secret here's that secret now you can verify that you can check that I'm the real client because when I started a flow I had the secret because I gave you the hash now I'm proving to you that I had a secret and the athe is like yeah we'll see about that that's what you say and it's going to recalculate the hash it's going to take that secret that the client provides in Step 11 code verifier it's going to calculate the sh 256 hash which is always the same if the input is the same and it's going to compare that to the hash stored in Step eight and if these hashes are identical then it is indeed the right client and that means that the client has received this authorization code in Step 10 for John It's associated with the same flow that was started in four and everybody's happy and we get the tokens and if the attacker comes back with their code injection attack they're going to insert an authorization code somewhere else and that somewhere else is not going to have the right code verifier it's not going to have the right secret so the STS at some point will be like yeah nice try go away and that's how we protect the Integrity of the flow with Pixie all right what does that look like in practice we've seen that but I'm going to reiterate that just for good measure in that initialization step in four imagine that it says four here just roll along with seriously if you build o I've rebuilt a lot of slides for this and there's always a lot of some details missing so my apologies for that but in this step you can see in step line six the code challenge that is the Bas 64 you're all encoded hash of a secrets you can also see a code challenge method that's the hash function we used there's like only one relevant hash function shout 2 56 but it's for upgradability because in the future you want to use sha three or whatever and then you can just gradually upgrade as we go along but that's how we signal that in step four here and also which goes there in Step uh five good how do we provide that secret well that's a code verifier here in Step nine so the code verifier here uh line n sorry in Step 11 that code verifier that's a secret that we sent right there that's a secret that we used before uh that we calculated in Step number two that's pixie for you all right some details pixie has the code verifier and the code challenge the code verifier is that little secret that you calculate it's a random value between four 43 and 128 characters of length from the character set a to z uppercase lowercase numbers dash dot whatever details I mean that's how you calculate that and then the code challenge is the base 64 you're all encoded sh 256 hash of that value keyword here you're all encoded trust me if you ever implemented this and you missed that tiny detail it takes you like an hour of debugging to realize that you're using the wrong encoding and that's why it doesn't work but once you get there this works quite nicely and then it ensures that the same client initializes the flow and finalizes a flow it ties the steps together and it offers strong protection against inject or flow attacks flow injection attacks or other Integrity based attacks and back in the day when you're doing um o out you were supposed to use a state parameter for this purpose and if you were doing IDC there's a non value for this purpose and pixie replaces both basically so if you use pixie you can forget about State and forget about nonis Pixie handles flow integrity and pixie is a rock solid best practice all right has become a security best practice for all authorization code flows many advantages to it so absolutely highly recommended all right by now you're probably thinking like holy crap if I have to implement all of that that doesn't sound like a good day that sounds like a nightmare well here's some good news modern libraries handle all of the heavy lifting in a modern Library you don't really have to implement all of these details if you saw the library I've been using before in the IDC demo it's like hey run a flow please handle this for me and the library does everything here's a couple of examples if you want to build a Java spring application there's a whole lot of spring sessions here spring has support for pixie built in so generating the code verifier keeping track of it um sending the code Challenge and all of that stuff stuff is integrated right there here's an example from passportjs a nodejs library pixie support built in pixie has been around for a while and Library support and then net has something similar and I stopped here with finding examples but we could keep going on and on about this pixie is well supported the O flows are well supported so today as a developer you implement this with a library and you're good to go so all of the heavy lifting including the flows and the Callback and the code and all of that stuff is handled by libraries and that makes your life pretty awesome actually good let's look at pixie in action the easiest way for me to show you how pixie works is by running a flow in flow simulator so let's do what we've been doing so far we run an authorization code flow as a confidential client and when we initialize the flow we have a toggle here that enables pixie and if you enable pixie for this flow you can see that we add the parameters here the code Challenge and the code challenge method that's how we signal to the STS that we are using pixie and how we do that all right when I initialize this flow remember we're authenticated from before and there's an active session between our browser and STS so we don't have to authenticate again I'll talk about what that means in um in a bit in the presentation but for now this means we'll just skip ahead to receiving the authorization code boom here's the authorization code this hasn't changed from before it's just a code AS we've always had when we exchange the code for tokens that's where things change because now we have a code verifier listed right here this was a random value that we calculated in the beginning that we will now present to the STDs to prove that we are the right client and if we ex change that code for tokens you can see that we obtain our token just like before that's pixie In Action Now what does this mean let's do this again and let's temper with Pixie so we initialize the flow we enable pixie not this one pixie there we go we receive our code just like before and I'm going to copy this command and I'm going to run this in a terminal let me make it a bit bigger so now this is the command that would be exchanged by the flow simulator or by the backend web application what we're going to do is we're going to temper with the code verifier let's change the one into a two because why not what this means is that we're presenting a different secret value like our little secret all of a sudden it's different and it will not match the hash that is stored by the security token service and this should blow up in our face with a an error and it does that's a good thing always happy when it does and it says invalid Grant failed to verify the code verifier so the SDS was like yeah yeah let's see if your secret actually matches the hash that we have stored with that authorization code they recalculated the hash which is different now because even changing one tiny bits in the data as input will result in a different hash that's a property of a hash function and the hash is different now and that means that the exchange fails and this should also illustrate that the authorization code is one time use only I believe I if I remember correctly that it's now invalid which is kind of a decision of the STS they can implement this however they want but if you try to do this it will fail um because it basically says like Hey we're try to exchange that code but it's no longer valid and that's essentially what's going on and if we would go at our OD zero tenant this is my rest grade out zero then I use for demos so there's nothing sensitive in there if you look at the logs you will see this as a security event as well there's a failed exchange right here stating that our demo backend is trying to do this and it said fail to verify code verifier this is something to be honest that you don't really want to see your logs because no legitimate case will ever end up on this unless you have an implementation error somewhere this is very likely to be some malicious behavior of somebody tempering with that information all right good I've been talking for a while now based on my timer so um what I want to do next is as a short little break in the presentation I want to run a little quiz so in my trainings I often run cahoot quizzes uh to recap what we talked about so far um which people always have great fun with now there's one thing I didn't really calculate for um I only realized that when I saw the room fill up um I'm not sure if my account can handle so many people so uh we'll see we'll see what happens usually my groups are smaller um so what you're supposed to do is you're take out a device um like a cell phone or a laptop whatever and join our cahoot quiz by scanning the QR code or entering the pin and then you can um we can see how well you grasped this oout knowledge here and if you can't join my apologies uh for that just play ahead along in your head and get a perfect score for everything so you win of course it's fluffy dog not fluffy cat Ju Just see this is the first time I actually can check kaho's implementation limits so we'll see that's interesting I thought well they claim the limit is 100 so apparently we're good so no need to upgrade that's awesome all right what's going to happen next is there's five questions um multiple choice either true false or like four answers where you have to pick the correct one if you're right you get points and if you're fast and right you get more points so um that's basically how how this works all right I guess most of you are here okay apparently not so let's give let's give it a minute it's fine good people people leaving and choosing other nicknames that's that's all fine good always a good indicator of how serious people are so I've had workshops where people have played with their own name for two days straight and there's other workshops where after the first quiz it just goes down the drain with stuff like SQL injection and things like that so yeah I've been doing this for a while I haven't seen cahoot fail so that that's a good thing all right let's go um if you're still joining you'll pop up as we go along like I said five questions about understanding oot and openconnect all right true or false o and open ID connect can be used together what do you think about that that's awesome wow um that's true so one of the use cases was oidc separately oat separately or a flow where you combine two together so if you ask for an open ID scope and an oat scope you're running the same flow for dual purposes you'll get an identity token and an access token in the same response and you can do whatever you need to do with that in practice all right devox is fun I agree so uh that's pretty awesome number two which token is specific to open ID connect all right then things get a little bit more complicated so the identity token is specific to open ID connect you only get an identity token if you're running an oidc flow it does not exist anywhere in the O specs it only exists in the open ID connect core specification that's where it's defined where the meaning is explained and so on so that's not an O thing that's an oidc thing all right number three which St does the client use to access an API all right good API access is the access token that that's an O token that also has a specific meaning in opened connects which we're not really going to talk about but that's essentially what the client presents to an API when trying to access it and what the API uses to make authorization decisions which we'll talk about later on all right you can see minor changes here um let's go to number four true or false pixie is a best practice to preserve the Integrity of an authorization code flow is that true or false good awesome job so that's absolutely what pixie does um it's about flow Integrity replaces the state parameter or the nons in open ID connect flows which were co-opted to preserve flow Integrity but pixie solves the problem uh in the core of the flow which is a much better approach by the way all right the top two stays the same so it's it's tied at the top for first place so we have one more let's see if that makes a difference final question what temporary value to ow out clients exchange for tokens what's the right one here all right this things get a bit more interesting so the authorization code flow essentially returns a temporary authorization code to the client which gets exchange for tokens in the code exchange that's essentially how this works client credentials are involved but they're not temporary values they're actually specific values for a client the redirect URI is present in the exchange but it doesn't really get exchanged for tokens because that's the authorization code and the sign challenge um kind of decoy the authorization code is whatever the SCS wants it to be so it's not typically signed it's just a random value stored somewhere and that brings us to the podium a five out of five for the top three so that's absolutely a good job and we'll see who takes first place you get zero prizes for that by the way so just just take the honor of it um and claim it by making a screenshot otherwise nobody will believe your mha but all right and let me grab a picture as well because this is definitely the biggest cahoot I've run uh so far so that's uh that's pretty awesome I want to get one from the screen as well usually the presentation screen is not that big uh it's a bit smaller all right great if you have some time towards the end um I don't know yet if we'll get there but if you have some time towards the end then we'll run another one all right let me go on for a bit and let me check in a bunch of slides in I think in about half an hour we'll have a break um 50-minute break where you can stretch your legs and take care of other business that needs taken care of I'll leave it in the middle what that is Maybe some of you have an addiction that you want to satisfy that's that's all fine all right so that was the basics the authorization code flow how to get tokens what about long-term access remember use cases I talked about like Zoom having access to your Google calendar or buffer the social media scheduling tool trying to access um LinkedIn or masalon in my name that typically requires long-term access as in days weeks months eternity and that's where refresh tokens come into play because the access token that you use to access apis is not supposed to be valid for like two years that's not really a best practice instead the STDs can give you a refresh token and that refresh token allows you to get a fresh access token that's essentially what this means and to do that you run a refresh token flow and a refresh token flow from now on the flows get simpler significantly simpler and the refresh token flow looks as follows the client in this case our backend web application goes to the SS and like hey I got a refresh token from before by the way I'm this client client ID client secret can I get a fresh access token and the STS will look up that refresh token be like oh yeah I gave that to Philip three days ago or five weeks ago and yeah this is still valid of course you can get a fresh access token and there we go and now the backend can access the API with that access token and everybody is happy that's essentially how this works the client decides when to use a refresh token gives you some flexibility in implementation you can monitor API responses just throw a request to the API um and if the API comes back like hey your token is expired you give me like oh yeah whoops my bad go to the STS you with a refresh token get a fresh one and make the call again or you could be a little bit smarter and you could Implement a preemptive check with the expires in parameter so the response from before would include an expires in like hey this access token expires in an hour so the application could Implement something that says like hey if I make a request after that hour I know that I have to run a refresh token flow first so I'm going to do it first before sending the request to the API that's definitely possible as a client you can make things simpler for yourself as well instead of storing access tokens and checking expiration a a tool like buffer they don't need frequent access they don't need to hit the LinkedIn API every 3 seconds or every minute I don't post that often like maybe once or twice a day and even then I have long periods of Silence so that makes no sense to keep track of the access token it's going to be expired anyway the next time you need it so why keep track of it at all and that's where the application can actually decide I'm only going to store refresh tokens and you know what whenever I need to make a call I'm going to Def facto use the refresh token with a refresh token flow so we can actually get a fresh access token and make the request that we need to make that's also an implementation scenario we can do in practice and that's actually um what I implemented in one of the demos um as well but there's to to be honest there's not much not much interesting to see about using a refresh token it's making a request getting a response reading the Json and dealing with it so we're not going to dive into the details right there let's talk about some interesting tidbits how do you store a refresh token well refresh tokens are kind of sensitive imagine your buffer and you store refresh tokens for LinkedIn and masteron access I mean if somebody gets those tokens they can access my LinkedIn profile that's maybe not ideal depends on what you want to if you want to run crypto scams then that would be ideal but for me as a user probably not and that indicates the importance of protecting refresh tokens and this use case is very relevant because buffer actually had kind of a problem before where they were breached and somebody stole their refresh tokens actually the story is a bit more nuanced as in buffer was using a third party to run their data storage and that third party got breached and buffer was the victim and so on and so on but in a nutshell the attackers stole refresh tokens it can be like yeah but doesn't the client need to authenticate to use a refresh token it's like yes that's correct if an if an attacker would steal use SQL injection steal refresh tokens from a database they can't really use them without the client credentials the attacker would be stuck with refresh tokens that they can't use but in Buffer's case here the attacker also got their client secret for I don't remember which what which it was I think Twitter and Facebook and with that client secret of course they could exchange the refresh token for Access tokens and with the access token they could access people's accounts and started posting spam uh very fast and this was a bunch of cleanup this is 10 years ago by the way so uh buffer has stepped up there security since but this shows you how relevant it is to protect your refresh tokens it should be considered as sensitive as user credentials because better safe than sorry in this case so you should store a refresh token in an encrypted format not just in plain text in the database all right of course if the attacker gains access to your encryption keys and your secret and so on we are still in massive trouble so a better pattern here or a better solution would be to move refresh tokens out of your main application into a separate service the token refresh service something you can run inside your application architecture but as a separate service with a separate data store which just Maps refresh tokens to users or whatever and there you'd handle the token exchange that means you can isolate that part means the breach here doesn't automatically compromise all the refresh tokens and that helps you to secure this in practice that compartmentalization is a really useful approach to move the sensitive data out of your main application storage into a separate service which you can better protect and better Shield all right how does a client get that refresh token well that refresh token is returned in Step 13 in this slide so the STDs where's my highlighter here the SS decides to return a refresh token right here in the flow alongside an access token and maybe an identity token depends on the configuration of the flow now how you get that refresh token there there's no consensus on that sometimes you can just configure the SDS as the administrator you can be like hey if this client asks for tokens always give it a refresh token that would be one option another option that's often used is the client asks for a refresh token at the start of a flow by including a scope called offline access and that offline access scope represents a scenario we talked about like buffer would like to have access to LinkedIn when I'm offline when I'm not actively running flows to give tokens but just offline when the user is not present and that's the meaning of that scope but this is not standardized that well so it depends a bit on the implementation on how this is actually handled in practice all right brings us to another question what's the lifetime of a refresh token and that's where things where we basically up in the land of the free we went from like this is what the spec says to like open-ended scenarios and this question is perfectly a perfect example of open-endedness nobody knows whatever you think is a good lifetime there we go that's it seriously that's it's fully at the discretion of the STS some applications have eternity as a lifetime of a refresh token some applications like LinkedIn have a a short lifetime of two or three months I know that because after a couple of months buffer comes back to me with a mail saying uhoh we couldn't post your LinkedIn profile and I have to go back to buffer and click the connect to LinkedIn button which will run an authorization code flow with LinkedIn so buffer again get fresh tokens so they have access again but ultimately it's at the discretion of the SDS they can be hours months eternity SS can change it whenever they want and they can make it dependent on the type of client you can say like hey this client never really needs long-term access that's not the use case that we're implementing here so you get a refresh token for 8 hours or this client like oh yeah they need long-term access you get an eternity refresh token or something in the middle or you can have inactivity timeout like if you it's valid for two weeks but if you haven't used it in two days then we're going to invalidate it anyway and things like that so there's a lot of flexibility in how you implement specifically so you can match your use cases if you're a client you should also be aware that a refresh token can become invalid at any point in time through revocation that's what you often see in these social scenarios if I would go to LinkedIn in my account settings there's going to be a setting that says like connected applications and buffer is going to be there and in LinkedIn I can be like yeah bam delete and that will basically LinkedIn will invalidate Buffer's refresh token so next buffer goes there LinkedIn is going to be like nice try go away invalid refresh token and access is gone basically so buffer will no longer have access in my name unless I grant it again through a front Channel flow where I can consent to giving buffer that access so that's how refresh token revocation Works clients can also revoke uh tokens themselves so for example in um the scenario I showed you before where we can disconnect rest restor grade from virtual foodie um we actually do a token revocation step we go back to WR again and say like yeah we got this refresh token before but the user is telling us that they don't really want this anymore so you know what let's invalidate it let's make sure that you no longer accept it in the future and we can fully blow up our connection until the user decides to Grant it again that's essentially what you can do in practice with refresh tokens when a token is no longer valid and I mentioned this a few times the only path to recovery is running a flow where the user is present again front Channel user interaction either with an ongoing active session that's still there we'll talk about that in the next slide or where the user authenticates again and gives consent again and moves forward but once a refresh token is invalid it's no longer valid there's no offline recovery that's why buffer sends me that email or notification like uh oh we couldn't connect to LinkedIn that's why we need they need to send that message so I have to be present to allow them to access LinkedIn again all right session reuse and single sign on sounds like a highly complicated topic but actually we've seen this uh just just a couple of facts I want to point out but we've seen all of this in action and this all of all of this makes perfect sense and you're probably fully aware of how this is going on as well I just want to highlight this in our presentation right here so whenever we run that flow I've always shown you like Philip authenticates with fluffy dog 7 and so on and so on but I only have to do it once and then my browser establishes an authenticated session between me and the SDS ss. rest.com and that session is based on cookies and those cookies keep track of who I am and that's why in the flow simulator we haven't re authenticated we just got the authorization code that's essentially why because there is an active session which is used for reusing or running a flow without user interaction and here's what that means so whenever whenever we run that authorization code flow and that what's that's what we have seen in action um the browser goes to the security token service the browser has a cookie from before from earlier includes that cookie in this request number three right here SDS looks it up it's like oh yeah you're Philip from five minutes ago I know who you are and it just responds with an authorization code bam so this is something you don't even see in modern browsers especially with good internet like here at the conference it's just like a redirect with an immediate redirect back so you don't even see a white Flash just like bam done and the only way to see that is going to the network tools of the browser and looking at the requests or using the flow simulator which I've built for reasons exactly like this and now of course we go back in step five to the Callback endpoint with the authorization code we exchange it for tokens and we uh go back and that's essentially how you run that flow um with an existing user session all right one of the benefits of this approach is that you you can use this for things like single sign on if you have a bunch of Enterprise applications if you log into to your company and you have the HR management application and payroll and lunch ordering application and whatever else you're running I don't work for an employer so I have no idea uh whatever else you're running internally you log in once in the morning and then every other application use a single sign on that's because if you did this step on top for one application and the second one runs a flow that same session will be reused as long as you're in the same browser that's how single sign on works that's also when you do sign in with Google you don't really have to sign in with Google because everybody is logged into Google anyway that's essentially what that means all right this session is at the discretion of the STS that's the responsibility of the STS managing that session is not defined in any spec um it's up to the STS to handle that as they see fit nobody enforces any restrictions here if you have an SDS you can force us user authentication every time why not you can set session timeouts if you want to you can do whatever you want in these steps they are not defined in any spec um and basically it's up to you to see how you want to handle that terminating that session requires an explicit log out as you've seen me do in a few of the demos as well so I've did an explicit log out that's where you go to the STS and you tell the STS I want to terminate my session with you that means the next time you go there there's no active session you have to authenticate again to do something useful that's logging out at the SDS and that brings us to a second scenario called single log out I'm not going to go into detail here but one of the things you can decide is to force a log out across all applications so if I'm going to go to the SDS at your company if you go to the SDS and you terminate your session there maybe all of the clients that authenticated you you through that SDS also want to terminate your session maybe that makes sense because otherwise what's the point of logging out and that's called single log out and that's a bit of a complicated scenario there's two ways for the STS to do that and so on but that's also a possibility um it's not mandatory to do that it's not often well it depends on the use case of whether it's implemented or not for example sign in with Google is not going to implement single logout because imagine you logging out from your Google account and every other application that you sign in with Google so all of a sudden logs you out that's probably not desirable but in an Enterprise setting that definitely makes sense all right there's no official link between session lifetimes and token lifetimes so your active session with the STS can be valid for an hour and your refresh token can be valid for eternity there's no requirement to link these together sometimes they are linked depends again on the implementation like this slide is all options and no no um mandatory guidelines it's all possibilities depends on what you're implementing depends on how sensitive things are and depends on how far you want to push things all right the client can also control user interaction open ID connect introduces a prompt parameter and the prompt parameter parameter can be used to tell the STDs whether you want to avoid user interaction even when 's no session do not prompt the user or whether you want to force the user to log in or you want to force the user to um to agree to a consent dialogue you can control that a bit and a prompt parameter fits into the flow in step two the client can here um set prompt for example to n that's a request parameter because obviously o likes request parameters so that's how you signal the SDS like hey I want to set prompt To None meaning that even if there is no active session do not show a login dialogue if there's a session give me a code if there's no session just give me an error message so I know about that and I can deal with that um myself and that's the SDS handles that based on the parameter and I can show you what the effect is of this all right guess how we're going to show that with the flow simulator of course so we're not are we logged in yes we are logged in we have an error here for because we tempered with Pixie but we still have an ongoing session with the STDs so um let's log out to kill that session there we go so now we have logged out of the SDS so there's no active session going on if we start a new flow we are still the same clients that will change uh after the break I think or maybe before I don't know I should know but I don't know every one of my 120 slides by heart so if we run a flow let's run one with Pixie we can control user interaction by setting toggling this thing right here and we can set prompt to none and you can see this in the URL now we have a prompt equals nonone parameter added at the end and what this means is we will go to the STS the STS is like I don't have a session I don't know who you are and it's going to send us an error message instead of prompting us for a login form so let's do that and see this here and you can see that the error message is login required and the error description is human readable login required and B basically tells the client like yeah we tried you told us not to bother the user we failed here's the error message that's essentially what that means all right this is useful for running things like silent flows bootstrap flows for example a client could choose when it loads like yeah you know what I'm going to run a flow with prompt set to n just to see if there's an active session if there is one I'll get my identity token and I know who the user is and I can just immediately authenticate them without them having to click a login button that's one of the use cases we have with this flow running a silent authentication flow allows the app to bootstrap itself with tokens and not prompt the user for logging in all right let me check no we'll talk about other client types before the break um which is coming in like 10ish minutes hold on for a little bit longer you can do it I believe in you um and it's all on the record by the way so that's something else uh the prom parameter is part of the IDC specification this is really messy so IDC added it but o implementations which mostly support oidc anyway they also support it so you can also use it for o out flows and so on and there's four values nonone meaning no using interaction a login meaning I want to force or I want you to force show a login dialogue even if you if you know who the user is let them log in again um we can do consent as in I even if the user has given consent before I want you to pop up the consent dialogue again which can be very useful for consent based scenarios and then there's a select account value which is basically what Google uses so whenever you choose sign in with Google you don't just silently go back to the application no you get this Google page saying like hey which one of these 15 Google accounts do you want to log in with because if you're anything like me you actually have like 15 accounts you have two of your own and then one for the kid school for this kid and then one for that kid and it's like this one that's a select account you can force that popup by setting prompt to select account of course the SDS can decide to handle this however they want they can ignore you they can do something else but in general that's the idea of the prompt parameter useful for background scenarios running a silent flow during bootstrap um used very much in front end uh applications by the way running a silent flow to a renew access tokens or refresh tokens that's all possible all right silent flows rely on that users browsers active session rely on that cookie being present otherwise the flow will fail and in many scenarios we'll deal we have to deal with things like third party cookie blocking and so on but that would take us way too far for this session here today all right so far we talked about backend web applications if you read the original o speec the one from 2012 you'll see that there's also other types of clients like front-end web applications or maybe even a mobile app and then you'll see that in 2012 by the way mobile apps were not really a big thing it was like yeah yeah whatever and then mobile apps became this big thing and we had some struggles with mobile apps and um we actually have a dedicated spec um identifying best practices for mobile apps which is where pixie came from it was a measure introduced from mobile apps the current best practice today for mobile applications is running an authorization code flow here's how that works so our client is now a mobile app hence the beautiful icon of a mobile device there and the user is um that error is not supposed to be there um in anyway the The Client app when it runs a flow runs an authorization code flow with Pixie you can check all of these slides by the way three times for the presentation there's always going to be an arrrow in the wrong place um that's just life when you talk about o the client in a mobile scenario is going to run a pixie based authorization code flow so what what does it do it calculates that code verifier calculates that code Challenge and it starts a flow with the STS and starting a flow basically means launching an embedded system browser so the app is going to launch an embedded system browser not a web view but an SF Safari view controller or Chrome custom tabs like the actual system browser EMB better it in the application it integrates nicely um doesn't really pop up a full new browser it's in the application but it's in browser based environment and that browser based environment is going to follow a url url taking it to the security token service and that security token service is going to handle user authentication who are you guess what I'm Philip and my password is still fluffy dog 17 exclamation mark and when that's done the mobile application uh sorry the security token service is going to store the authorization code with the code challenge just like before it's the same flow and it's going to send the code back to the application and that's a redirect in the browser which will then open the application back up and deliver the code to the application that happens in Step number nine at the bottom and the application can extract the code and exchange it for tokens it provides the code verifier there but no client authentication you can't a mobile application doesn't have a client Secret because guess what if you embed a client Secret in an Android app it takes like 3 seconds for someone to get it out and off you go so there's no client secret it's just a public client we call it a client without authentication and SDS will be like who are you oh what's your code what's your code challenge of code verifier match it to the code challenge like before in Step 11 and then return the necessary tokens in Step 12 allowing the client to handle whatever it wants to handle that's the current best practice for mobile applications sounds mightly complicated but it really isn't in practice it's the same steps as before there's libraries handling this for you so you don't really have to implement any of this Yourself by the way we have no client authentication in Step 10 that's why pixie was introduced because somebody figured out on mobile it's a bit easier to intercept Step n and since there's no client credentials in Step 10 anybody with the authorization code can exchange it and that's why they added pixie so it becomes impossible for a malicious app on your device when it steals a code to exchange it because it doesn't have the code verifier because that one is stored in the legitimate app not accessible to the malicious app just as background information this is awesome from a single sign on perspective this is great because a mobile app is using a system browser guess what that system that embedded system browser has cookies if you're logged in do your main Chrome browser on Android U the embedded system browser will have that session so you have single sign on for mobile apps which is not a bad thing to have the downside of this your marketing people will hate you if you tell them like yeah we're going to run this embedded browser like what the hell is wrong with you that's a bad user experience you want to stay in the app and today there's no real good answer to this yes you'll find custom implementations of getting credentials and forwarding behind the scenes to the SDS yes and that is not a recommended best practice yet because there's a whole bunch of security issues to take into account I'm just giving you the rundown from mobile app so today the best practice is running this with an embedded system browser however in the O out working group there is active work going on to provide a more native user experience for mobile apps and they're looking into using things like app at a station to implement something like a sort of authentication to protect this step but for now there's no offical recommended way to do this which translates to if you'll find SDs implementations that have their own way of making this happen and I'm going to leave it in the middle whether that's a good idea or not it's not a recommended best practice and if you do it there are some serious consequences but keep an eye on ongoing work because maybe in a few months we'll have a more official recommendation of how to handle this in practice all right we talked about that um we talked about that so Ed browser is not a web view because the reason is in a web view the application at loading the embedded browser can still interact with the web view they can see what the user is doing they can monitor credentials and that's kind of the whole point of not exposing those to client applications and in a system browser you can't monitor the behavior inside you can tell it something like load this but that's it you can't monitor user behavior and that's the recommended best practice and then the mobile app has refresh tokens for longterm access that's whole the whole idea on mobile apps you don't want to authenticate every time you use the app that's really not how it works with a browser and username password and multiactor but the mobile app will get tokens and one of these tokens is a refresh token which can be valid for a long time and the mobile app can store that refresh token in Secure Storage like OS protected Secure Storage often protected Biometrics which is why if you open the app again you're asked for your fingerprint or phase ID which will unlock the store tokens which will allow the app to to access apis on your behalf all right those refresh tokens are extremely sensitive remember before the buffer example backend web client you needed client credentials to exchange a refresh token but a mobile app doesn't have client credentials so you need nothing to exchange a refresh token which means if somebody steals that refresh token we are in a world of trouble like literally a lot of trouble and that's why there's an additional security mechanism called refresh token rotation and refresh token rotation basically assumes that if somebody steals a refresh token and they use it that's not really supposed to happen if a refresh token is used by the app on one end and by an attacker on the other end that's a big problem so in that case we'll just blow it all up well I have to be careful with that statement like we'll just invalidate all tokens that's more more uh less panicky will'll invalidate all tokens and stop that flow that's basically what this means so here's the legitimate use case the app obtains tokens at1 access token one and rt1 refresh token one and H1 expires after let's say an hour or 10 minutes or whatever and the app can use refresh token one to obtain fresh tokens run a refresh token flow no authentication but the response contains a fresh access token and and a fresh refresh token so now the app has access token 2 and refresh token 2 and when access token 2 expires or is about to expire it uses refresh token 2 to get access token 3 and you can see where this is going right and I have one more because then the slide is full and we use token refresh token 3 to get tokens at four five six until the absolute lifetime of the refresh token chain is reached let's say after a year and then we lose access alog together and the user has to reauthenticate that's essentially what happens here how does this work for security well because the STDs monitors abuse of refresh tokens so let let's imagine that something like this happens the app is humming along and doing its refresh token exchange and blah blah blah and then the attacker steals refresh token to one way or the other whatever and the attacker uses refresh token to and the SDS doesn't authenticate the client so the SDS is like oo refresh token to here access token tree and refresh token tree and the attacker is like bam and they can access the API on your behalf which is bad and they can use refresh token tree to get tokens at four five six whatever this is bad however the app is unaware that this happened so the app at some point in time is going to be like oh let's use refresh token 2 and that's when the protection kicks in that's when the STS says like what you've done that before well somebody done that before this is not what you're supposed to be doing and that's when they the security kicks in the STS will invalidate everything that followed from refresh token 2 and make sure that the attacker loses access because of this abuse scenario and that's refresh token rotation all right mandatory for clients that cannot authenticate so public clients and guess what I can show you how that works in practice I like these little demos by the way this is fun so let's run this we use a different client it doesn't matter let's run this as a public client let's um ask for a refresh token in this case we have to use that scope let's use pixie as well and this is just an out zero implementation detail we have to ask a token for an API to get a refresh token so don't worry about this all right this should work we this authenticator unauthenticated before to show you that error message when prompt was none so let's reauthenticate let's exchange the code for tokens just like we've done before notice by the way notice here we're a public client so there's no client credentials just exchanging the code for tokens without credentials and we obtain our tokens and we can see that we now have a refresh token and the refresh token is only meaningful to the STDs it looks like whatever the SCS wants to wants it to look like and this token was issued today that's how we see with live because there's a time stamp in there which I can make up by the way but I didn't so uh let's run the refresh token flow how do we exchange it well the grand type is now refresh token what are we exchanging for tokens a refresh token we are this client and here's our refresh token and we exchange it and we obtain fresh tokens including the refresh token here was V1 mq STV and the new refresh token is V1 mg STV and that's a different one and we can do it again and again so let's take a look at what happens if we do it again and we steal the refresh token we're now the attacker and in our life it's as easy as clicking this button and we have now stolen the refresh token so what we can do is we can exchange it for tokens we're the attacker now we have stolen this there's no secret in here all you need is that refresh token to exchange it for tokens and Bam there we go and we get a fresh access token and a fresh refresh token and you can do it again and again and again if you want to until let me just a second let me paste this request right here because we'll need it in the future this is the new refresh token we got from the flow let's paste that in here to use that in the future up there we go if we run this we would get the next refresh to but first we're going to run the same request as the client and if we do this we get an error message saying like no no no fail to exchange a refresh token we go here to the logs and we'll see refresh token abuse something something so or not just give it a second no apparently we will not see that that's kind of weird um doesn't matter we can try the request as the attacker this is where the demo is going to blow I can feel it no if you try this now it says like unknown or invalid refresh token that's expected Behavior that's the new one but we used rt2 twice so rt3 which is this one gets invalidated towards the future I'm very uncertain why I don't normally you should see an error message here as stating exactly that maybe the logs are a bit slow I don't know let's try it again yes there we go took a while for the message to arrive but here it says like reused refresh token detected that's basically the same refresh token being used twice and that's a security measure of refresh token rotation all right seriously five more minutes still to break I promise in those five minutes we going to talk about front-end web clients yeah front end web clients the story for frontend web apps is the same it's a public client it uses the authorization code flow so the slide is the same that has the same error by the way so some copy pasting work going on but the frontend web client uses pixie calculates a code verifier stores it in the browser calculates a code Challenge and starts a flow it's a front end web app so it runs in the browser but it basically navigates the page from the front end away to the SDS to make that flow happen and the browser will follow the navigation send a request we authenticate as a user or reuse a session nothing changes here the result is an authorization code being sent back to the front end what does it mean sent back to the front end it means the front end reloads the JavaScript bootstraps and then reads the URL like oh there's a code in the URL yoink you pull it into JavaScript and you exchange it for tokens that's essentially step um number nine relaunching the front end the front end then reads the code from the URL sends a request to the SDS without client authentication because it's a front end you can't put a secret in JavaScript because it's very easy to read it and the security token service will issue tokens to the front end all right and the front end is very happy and we're very happy and now we have our front end angler app or front-end react app or front end fuse felt j c if you hate yourself whatever your front end app has now tokens to contact apis and if you're a fronted web developer you're like oh my God this is so awesome tokens yes no cookies I can just send requests to apis and I'm very good to go and the recommended best practices for this would be like yeah you can use refresh Tok or you have to use refresh token rotation and you can try to prevent token exfiltration and so on and so on because the problem with front ends is web front ends are crazy because of JavaScript a browser has this cool feature where you can translate data and make it executable code all it takes is one mistake in your application and then some data that looks like HTML and all of a sudden bam JavaScript code executing because you rendered a review from a user like what the hell that's Crosset scripting and Crosset scripting is this insanely dangerous attack for web front ends and it basically means that the attacker can run code inside a legitimate front end application that's the code right there the attacker has succeeded into running code in the user's browser in the application and that means game over and there's some recommendations about this like yeah but maybe you can do this and maybe you can do that and I've been working on this for a long time and we actually had the oout security Workshop um with all the people from the O working group um last month no two months ago end of August in in the UK and we talked about this extensively and there's no way you can fix this that's basically conclusion like if this happens you are done as in your user is compromised he ER will obtain tokens in the name of the user giving them long-term access on behalf of the user theer can steal an access token and a refresh token which basically is as bad as it gets when it comes to O out access token and refresh token in a web frontend scenario that refresh token is f it for maybe eight hours that's very common guess what that's eight hours that the attacker can be like bam I can do whatever I want in the name of the user and nothing can help here not even refresh token rotation this is an absolute nightmare all thanks to HTML and JavaScript by the way the same holds for mobile apps if you build like these fake mobile apps I have to be careful here because I'm going to get beat up by mobile developers but fake mobile apps where you basically have HTML and JavaScript packaged as a mobile app but it's basically a browser running a JavaScript based application the same story holds if you have a native app that doesn't do crazy things like translating data into executable code you're fine but the moment you have a live data to code feature like JavaScript HTML parsing you are in trouble because the attacker can take control of the app and can obtain tokens in the name of the user I have zero time to talk about this in detail that's not what this session is intended for however I can tell you the best practice if you're building a security sensitive frontend web application which means anything else than your grandmother's recipe book anything that handles personal data anything that handles business data you're supposed to use the backend for front end pattern because the back end for front end moves the oout handling to a backend component where you use client authentication and all the best practices and then just asks your front and proxies request for your front end that's in a nutshell what the back end for front end does I know that this is absolutely useless for you as in like yeah what the hell do I do with that well I actually did a long talk on this there's a a talk from earlier this year from NDC security where I talked about the insecurity of O out in front ends and there I talk about the details of the attack at Great length so uh if you want to know more about this I refer you to that YouTube video it's about an hour of all the details of what's wrong with web front ends and the idea of how to fix it and if you look for the same conference there's a talk by Dominic berer on how to implement such a bfff for net and so on and that's the recommended best practice and actually after the security Workshop the security Workshop I started working with the people there's a spec on this called the browser based apps best practices for o and we're reworking that document to reflect these best practices as well to highlight the potential attack factors the dangers and the solutions that can help mitigate that problem but for obvious reasons like it takes me at least an hour to go through even longer I'm not going to do it right here I'd be happy to talk about this during the break when you get like a drink you probably need one right now after all this o stuff so let's have a 15 minute break until 20 before 5 4 no 22 4 and after that we'll continue with um more o stuff all right see you back here in 15 minutes all right hope you enjoyed that break I discovered that the camera tracks me by the way automatically so I can move whatever I want it's just going to go back and forth really fast so uh that's going to be dizzying on the left of the screen on the right of the screen but other than that we're good all right I had a bunch of questions during the break like I I really meant it when I said harass me I don't mind questions um some questions were about stuff that's coming up so I told people like come back after the break because we're going to talk about that but other questions um some of them I could answer some of them I couldn't uh I don't know everything either but I'll do my best to answer anything you have all right before the break we talked about o out in case you haven't noticed we talked about the authorization code flow in depth we talked about a user facing flow that's essentially what this meant user facing every user facing application today barring some really specific use cases will rely on that authorization code flow with Pixie remember that authorization code flow with Pixie internalize that that's the goto o out flow for user facing scenarios but what if you don't have users well I'm kind of guessing you're a very happy developer if there's no users there's no user interface it's like awesome it's this machine to machine communication software are calling apis like yeah that's that's a pretty good Gig if you have that thank you for the encouragement trust me it is um in that scenario you can authenticate however the hell you want basically like you can use API Keys you can use TLS certificates you can do whatever you want because machine to machine authentication is really awesome to implement however if you already have an oout architecture if you already have an API that accepts requests coming from client dealing with users like the restor grade API then if you also need to support nonuser specific clients like machine clients it becomes a bit messy trying to implement two mechanisms because one is like yeah let's check these access tokens and then also maybe for this type of client check an API key like you don't really want to start doing that that's going to create too much complexity and that's where the client credentials flow fits in the client credentials flow in O out has been there since the beginning is super simple and is also the only flow that hasn't changed since 2012 because it's that simple you can't really screw it up um and the client credential flow supports exactly the scenario we talked about you have an API handling access tokens and if you have a client that needs to access that API directly no users involved it can get an access token to make that API call and that's the client credential flow and chances are you've run into this whenever you try to implement client access to a third- party API like integrate something with a remote API maybe they well very of often they're just like yeah copy this API and we're good but sometimes they tell you like here's a client ID in a secret and we want you to run a client credential flow to get an exess tokens you can access the API on as your client directly not on behalf of user directly as a client here's how it works the client is configured as an oout client the client is going to use an oout flow the client credentials flow to obtain a access token and that represents the authority of the client to access the API and examples include scheduled cron jobs uh giup action that need to contact apis configuration tools anything that doesn't involve a user that's essentially it how does the flow work the client goes to the SDS and says like hey I have this client ID and this client secret can I get an access token and the SDS will verify that against their list of clients like oh yeah your ID is registered and your secret is indeed this you know what that's good here's your access token and now the client can send a request to the API and API can verify the access token like it does before we'll talk about how that happens in a second but the CL the API just verifies the access token just like it would do with user based access makes an authorization decision and does what it needs to do so from the API perspective it's a uniform way of granting access makes sense in an oout landscape from the STS perspective it's just another client and the client well there's an additional step compared to using an API key but the overhead is minimal this is machine to machine straightforward all right like I said the flow is so simple that doesn't need any change in I mean this is all there is to it you send a request you get a response and you have a token what does it look like just for good measure and because we have pretty slides here the client credentials flow it starts with grand type client credentials what are we exchanging for an access token client credentials here's my client ID here's my client secret now can I get an access token please and the response is going to be an access token that's a response here response is basically an access token that expires in hour in this case can be shorter in because it doesn't really matter in this use case to have long lift tokens all right that's what's going on right here there's no refresh token why not because to use a refresh token we would have to use client credentials because we're confidential client but if you have to use client credentials we can just exchange those for Access tokens directly so there's no need for a refresh token whenever you need a new access token just send the request from step one again and you'll get a new access token and you want to do it again in five minutes then you send the request you get a new access token you don't even have to store access to well it depends a bit but you don't have to store access tokens because every time you need them you can ask for them of course some implementations don't really like it if you do that they don't like it if you run a GitHub action every five minutes that asks for a new access token because it puts a lot of load on a managed service and that's why they put some restrictions on how many times you can do this based on your plan so if you want to do this a lot you have to pay them a lot so it varies how deep your pockets are whether you want to implement token in or not um that's just a small implementation detail here the client credential flow fits into o out as a whole it's it doesn't really solve a problem that we have but it just makes sense if you're already building apis that handle o access tokens then it doesn't make sense to implement a secondary client authentication mechanism with API keys or tser and it makes much more sense to just integrate something with access tokens as we've been doing all along and that's what's going on right here no users involved no access on behalf of a user just straight up clients to API access all right this flow only works with confidential clients you can't do this with a client that doesn't have a secret because that would make zero sense at all so that's that's why this flow requires client credentials hence the name client credentials flow or Grant all right that was the easiest o flow you'll ever going to find so uh yay for that and that covers the flows there's a few more the device authorization grant for example the device flow is what you use if you want to pair Spotify or authenticate to Spotify on an Apple TV because guess what there's no real easy authentication so they show you a URL like go to Spotify something something enter this code and they can complete the flow on your cell phone and it authenticates or gives tokens to the app on the Apple TV stuff like that we're not going to talk about those if you want to learn more I um I can point towards that later good that brings us to the part of O out where things get a bit murky because o out and all the specs what they mostly focus on is that interaction between the client and the STS like the flow with all the steps to get tokens and then once you have tokens it's like me you you deal with that and there's some pieces and bits that are there um but in general there's a lot more flexibility and open-endedness on that part of the O landscape and we're going to talk about two things here we're going to talk about Scopes how you how you can use Scopes and then we're going to talk about access tokens different types and how an access token is handled by the API and once we've done that we have reached the end of the session right here what's the purpose of a scope what is a scope well a scope is anything you want it to be the the O spec defines the scope parameter says like yeah you ask for a scope here that's how the STS grants a scope but what you do with that like yeah whatever Scopes are a string value with space The Limited entries so it's like one long string with spaces and every space denotes a new scope that's essentially what this means so o provides it it defines the format but it doesn't Define any values it just says like yeah you can use this however you want o IDC on the other hand is like oh in that case we're going to use a scope to make an o out flow and oidc Flow by adding that open ID scope that basically takes an existing o out flow and metrically transforms it into an oidc flow that's an open scope and other than that you can Define your own Scopes custom Scopes and you can do whatever you want with that that's how Scopes work in practice I know that's not very useful like do whatever you want it's like yeah okay and now what do we do with that thank you depends on what you're building if you're building Google which I I probably doubt you are but if you're building Google then you have like a few hundreds or even thousands of Scopes and if you look at this I don't know if you can read this but the screen is big enough for sure but if you look at this you'll have um where's my highlighter you'll have scopes for Gmail if you want to build an app that accesses a Gmail API you can request one of these Scopes and as you can see in Google um they have compartmentalized the API features into certain scopes for example if you're building a depressing productivity app that shows you at the end of the day how many unread emails you have in your inbox I mean that's a good way to kick somebody when they're down at the end of the day you don't really need the ability to send emails in the name of the user right all you need to be able to do is read their inbox so there's a scope for that gmail. read only and that allows you to request the minimal amount of Scopes needed to perform the operation as a client application against Google against the Gmail API and that's an interesting take and Google uses very long scope Scopes because they want to use the scope to differentiate between different apis I mean read only on Gmail means something entirely different than read only on the calendar API right so you can't just use read only and then hope that you can figure out where it belongs that's why they add gmail. readon and they use a full URL in this case and you also have the full scope like mail.google.com gives you full access to Gmail um and based on what Scopes you're requesting Google can and maybe have some certain policies like hey if you want to build a client that accesses full access to Gmail you have to subject yourself to a third party Security review and so on and so on but that's just policy that's no implementation of that all right now for everybody not building Google your Scopes probably don't look as clean as the Google Scopes in reality you'll discover a lot of tech depth in Scopes and a lot of weird changes in behavior and GitHub is a very good example of that you can see how GitHub Scopes grew naturally because they have some um some subdivided Scopes like repo invite and admin Scopes but also some some weird things like public repo and just the repo scope alog together and you can see that they started subdividing Scopes after a while and read write but sometimes they don't and so on and so on that's normal I mean Scopes are a mess that's that's basically a given if you're dealing with Scopes I wish I could tell you the one and only way to define Scopes but there is no one and only way to define Scopes it's all about what you want to achieve with a scope Scopes are very often linked to consent that's kind of the rough idea of a scope like the user let let me try to explain what the idea is behind o out and behind Scopes let's use Google as an example I as a user in O terminology I'm the owner of my Google account Google definitely disagrees with that but in a terminology I'm the owner of my data the resource owner right I have full access to my Google account I can do whatever I want on my calendar I can do whatever I want in my Gmail inbox I can basically do and I'm I'm the owner I can do what I want if a client wants access like Zoom wants to access my Google Calendar I do not want to give Zoom full access to my Google account that would make zero sense to do that and Scopes are a way for me to Grant certain authority to zoom so Zoom will have to ask for a scope in this example Zoom will ask it's not on the Google slide I had but Zoom will ask like hey I would like read and write access to the calendar API and Google will authenticate me and then pop up a dialog like hey Philip are you sure you want to give Zoom this access to your calendar because it's it's important to have that consent because otherwise Zoom can do whatever I want whatever it wants on my calendar API without my consent so I have to say like yes I explicitly want that to happen or no I do not and that's a consent uh related to Scopes and then when everything is approved Zoom gets a token and in that token there will be a scope parameter saying like hey calendar read calendar write or whatever the actual scope is and that's how I can delegate partial Authority for my full AIS I can give like a very small subset to a very specific client because they asked for it and decide that that's a good idea that's the concept of Scopes and then after a while as always if you give people the option do what you want with that people do crazy things with Scopes and you'll find applications where you have like hundreds of scopes and clients have to ask for like a whole gazillion configuration of Scopes and you run into like token length limits in headers and it's like bad idea in general you're supposed to try and keep Scopes as as fine grained as needed without going haywire on that if you have a document like a 12-page document describing your Scopes you're probably not using Scopes the way they are intended to be used and you might want to look into other ways of handling authorization some rules of thumb some guidelines of what you can do with Scopes let's say we're building a restaurant review application we have two types of resources we have restaurants and we have reviews right how would you define Scopes in that well you can see an example right here um what's the reasoning here we'll divide Scopes into two silos reviews and restaurants two different types of resources that will have different levels of access all right and now for each of these we'll think about do we need more fine grain scopes for restaurants well reading a restaurant there's no specific permission for that everybody can do that that's kind of public info but managing a restaurant there's only one client that will need that scope the restaurant manager application nobody will ever request that because we don't really allow anybody else to get that level of access to restaurants so there it wouldn't make much sense so we just kept the restaurant scope as it is for reviews well we have that third party access scenario right we have that virtual foodie app that will request read access to the users review so they can pull statistics and give you recommendations so we want to split out read and write access why so we can tell the user in a consent form hey user this application will only have read access to your reviews they won't be able to write stuff or post stuff on your behalf just read stuff and that's why we add a custom scope for reviews of course if you have read then it makes sense to have write as well we also have the lead as a separate scope why because users like to be reassured if you tell a user like yeah they might be able to read and write data but they can never delete data from your account that's a reassurance by having that as a separate scope you can tell them unless the application actually gets that scope the user or the application will never be able to delete stuff just as one example of a rule of thumb of how to handle Scopes in practice um of course your mileage may vary you can come up with all kinds of different patterns that work for your applications because usually you're not building a restaurant review application either the concept of Scopes as they are envisioned in the oout landscape is to allow a user to delegate a subset of their full authority to a client application and then closely related to that give consent for that and that consent really matters because I as a user have decided against granting certain permissions to an application because they were asking for way too much access I have a a scanner that can scan directly into evernote and the scanner is from router and the hardware is absolutely awesome and the software is the worst scanning software you've ever seen seriously I have to buy I had to buy a second application to scan with my brother scanner to make it work and when I wanted to try out the Evernote feature brother was asking it was using oat for this with Evernote apis and was asking like hey I would like to have full access to your Evernote account like all your notebooks read write delete whatever and I was like yeah if you can't get your scanning software to work I'm not going to give you that amount of access to something that contains potentially sensitive information and the consent step there I decided against that and did not grant that access so that consent really works same for zoom and Google if you want to click the zoom button connect your Google calendar and all of a sudden you see like hey Zoom can read your entire calendar and create appointments you can be like why doesn't want to read my entire calendar like no I don't want that to happen deny that's how consent plays a role here all right sure let's let's do another demo um things haven't blown up yet so uh let's see if we can keep the track record going this one is still running I'm going to disconnect it and we're going to reconnect it again when we reconnect it the reason I want to do that is um because it will pop up a consent dialogue and a consent dialogue here says in case the screen isn't big enough I can make this bigger exent dialogue says Hey virtual foodie is asking access to your restorate account and it wants to read your reviews and it wants offline access now what does that mean read reviews means the scope requested here was to read reviews obviously and the offline access is a Zero's way of saying we're going to give the application a refresh token so it can keep accessing your account even if you're not online anymore because it will have a refresh token why is this being asked because if you would inspect this application's code that's this application right here the oart configuration is here at the bottom or at the middle at the top whatever the Ohad configuration here is configured to ask for read colon reviews as a scope along with offline access that's how this ties in the client is asking for it the STDs in this case is deciding that they want to prompt the user for that and then once you get that um if you get that token it will be present inside the token as a claim and the API can rely on that as we will talk about later this consent is optional it's relevant in thirdparty scenarios like Zoom accessing Google Google wants to make damn sure you are on board with that because otherwise they're in big trouble If you deny or if you're not on board and they did it anyway in a Enterprise setting in a business setting consent is often very implicit if you're an employee your company's application is not going to ask you if you want to allow your company application access to your company data on the company API they're going to be like yeah yeah whatever that's implicit U of course you agree to that that's your employee agreement we can handle your data any way we want that's called a first party scenario and a first party scenario is consent consent is often implicitly handled in third party scenarios it's often very explicitly uh dealt with with consent dialogues and again it's not defined so you can do anything you want with that all right that's where Scopes come from Scopes from that point on started to live a bit on their own as in people run into limitations Scopes like reading reviews is fine but what if you only want to allow a client to read certain reviews like how could you handle that which for reviews doesn't make much sense but imagine you're building an ealth application and you want to allow the client access to certain patient records but not all of them read patient records probably not a good idea but read patient records for this specific patient like yeah we can we can deal with that as a scope and then all of a sudden you have Dynamic scope values scope values that aren't predefined as static strings but includes Dynamic identifiers and it kind of works on a small scale you can make this work in very close close scenarios where you control all of the parts you can have this kind of scope mechanism built in but they require a very close coupling between your STS and your authorization logic you can't do this on third party scenario it's it's going to be a mess if you try to do that and things evolved from there because um we started using o out for all kinds of features open bank is built on o but Scopes in open banking like a client asking permission to perform wire transfers from your account like wire transfers as a scope me probably don't want to say like oh yeah sure you can have permission to wire money wherever you want that's not something you want to do in that case you want to give permission to send 50 from this account to that account for a specific transaction that would be a dynamic scope but there's no way to express that with a string of space limited values and that's where raar comes in and raar is called Rich authorization requests and it's basically a highly detailed format for a client to ask consent for specific transactions with all the details included like I want to send this amount of money for that to that specific account in an online purchase scenario something like that and that's how that plays a role again I can't go into detail raar is a very new addition um it's highly relevant for these Advanced use cases in eal scenarios in uh Financial scenarios and so on if you're in that kind of use case um maybe useful to check out in practice all right let's talk about access tokens going to answer the question that somebody asked me during the break like how does API handle an access token well that's what we're going to talk about we're going to talk about the other part of the triangle so like I said before much of the complexity is right here let's talk about this part that's a part that's a bit less defined in the O spec there's some definitions uh but all in all it's implementation logic that you handle at the API side and to do that we have to look at how the client accesses API they access an API by sending an access token we kind of established that already the client sends a request like get viws and you typically you include an authorization header with a token type Bearer and you send the access token right there and the API gets it out of the header and then what happens well it depends on the type of token because o out has two types of tokens you have a reference token and you have a self-contained token and a reference token is an identifier it means nothing and a self-contained token is a token that contains all of the information that the API will need to make a decision and guess who decides what type of token that is being used to secure the token service your STS is configured to give a client an access token and it can decide on a whim usually it's configured but whatever you can have like a random number and decide like oh it's less than five so let's give you a reference token and otherwise you get a self-contained token in in reality you probably don't do that in reality you configure a client like you get reference tokens you get s contain tokens or you don't configure it at all because your SS only supports one or the other but clients should not be dependent on the type of token they can use or inspect a token for like Diagnostics or debugging purposes but you should not write client code that tries to open up a token inspect some claims because the client should not rely on that or is explicitly forbidden by the spec to rely on that in reality it's not always true but in practice you should take that to hard all right note that um identity tokens are handled by the client those formats are well defined and clients are supposed to process them but access tokens are not supposed to be processed by the client what does that mean for the API the API is expected to make authorization decisions so the API has to handle an access token so how do you handle a self-contained access token and how do you handle a reference access token let's talk about that let's start with reference tokens here's an example of a reference token obvious right if you receive this as an API it's like oh yeah of course that's SL you have no idea what this means a reference token is an identifier a reference to State kept by the security token service that's all it is and it basically means that the access token is just a placeholder and that the API has to go back to the SDS and be like hey I got this token from the client what does that mean and the STS will look it up in its database like oh yeah this ID or this reference I stored this state with that and it returns a bunch of claims to the API saying like oh yeah this token means this this this and this and AP is like ah excellent that means something to me and now I can make my authorization decision and this process is called token introspection and it's as heavy as it looks yes it's every request in Step One triggers a request in step two and a response in step three before you can make an a ation decision that's called token introspection here's a token introspection response what you see in step three and the most important claim in this response is on line two active it's a Boolean guess what it means you're smart people you can figure this one out um this bullan is either true or false if it's false the token is not active and you're supposed to abort immediately there will not be any other claims in the response by the way except active false if active is true that token is valid and you get all the claims that are stored at the SS associated with this token and those claims allow the API to make authorization decisions more on that later all right the SDS controls token introspection there's a spec that defines how to handle token introspection but the SCS can decide to give certain clients more information than other clients for example first party clients like internal clients they get much more information about an access token and maybe a third party client gets a few limited uh claims only that's perfectly possible not necessary but perfectly possible all right what's the benefit of using reference tokens why would you subject yourself to that pattern of sending a request to translate a token into claims control control over tokens revocation properties of tokens if you're building let's imagine you're building a banking app with access tokens and your access token is valid for 10 minutes that's a short window of time that's good but if somebody steals an access token and allows them to make wire transfers on a bank account 10 minutes of abuse is still kind of problematic well I'm not sure what kind of Bank you're running but in most banks this would be problematic so what you might want to do there is in case a token is compromised you have to revoke it immediately and with reference tokens you can do that with reference tokens you can actually you keep them at the STS all it takes is dropping a line from the database well probably you want something more sophisticated with an other Trail and so on but in my simplistic view it means the lead from tokens where access token equals this bam no token is no longer valid and the next time a request comes in to wire 2 million to Nigeria the STS is going to be like I don't know what the token means invalid active false and off you go that's the benefit of reference Tokens The Benefit comes at a cost right most of you are like yeah let's not do that so what's the alternative the alternative are self-contained tokens they're bigger that's their downside they're bigger the self-contained token contains all the information right there and it's encoded in most cases as a Json web token Json web token which is signed by the SDS with a private key so the STDs has signed that token and in that token are claims and those claims are the same as you would get from token introspection so how does the API handle that well the token comes into the API the API is like oo it's a self-contained token it verifies the signature like is this actually valid has somebody modified claims in the token has somebody changed the admin claim to True when it was false before signal verification will alert you to those changes signature verification will be like H this token is no longer valid and you can drop it all together but if the signature checks out if the signature is valid then the token is in the exact format as it was generated by the STS when they gave it to the client that's good next you check some additional claims in the token like a time stamp is this token expired because if the time stamp of exp expiration is in the past you want to reject it as well and so on makes sense right and from that point on you get the claims and with those claims you can make authorization decisions as we talk about later how does this work in practice well the API is configured with a trusted STDs you tell your API your API doesn't just accept tokens from all over the world no you tell your API like hey when we're going to accept tokens why don't we accept tokens from ss. rest.com and when you do that the API is like oh yeah that's a good idea well it's less for it's not Java so it's not that for both but and the SS is basically the API is basically going to be like okay in that case I'm going to load the signing key or the signature verification key from the SS so whenever I get a token I can verify whether this is valid all right all of that stuff is implemented in middleware fetching keys and all of that stuff is not something you have to implement yourself usually and you can do that in resource server libraries resource server that's the O out concept of an API of what we've been talking about it's a resource server and there's libraries for all modern languages to handle these Json web token based access tokens they will handle signat verification and will alert you when there's a problem or give you the claims when there is no problem all right if you really want to you can do token introspection for self-contained access tokens as well if you want to as in the token introspection spec says like yeah you know what if you really want to nothing prevents you from running a token introspection step for self-contained access tokens in case you want to make sure it's really valid even though it's supposed to still supposed to be valid you can do token introspection all right let me show you a couple of lines of code just to see what's going on to show you that let's go to the restorate API which has hardcoded data as all good apis um anyway what we do here is we're using in library like I said middleware to verify access tokens in this case it's Express O2 J bear as in it's a library explicitly intended to process JSA web token based access tokens and here's the relevant lines of code we configure our application to use it and we tell it the issuer base URL is ss. rest.com and that's it and this behind the sces will make a call to that authorization server to that SDS fetch relevant metal data from a spe specific do wellknown endpoint load that Json config file figure out where the signing keys are retrieve those signing Keys dynamically load them into memory and next time you receive a request with a token it will verify the signature on that token and expose the claims to the API and the claims are exposed in rec. out. payload that's basically where you find the claims of that JS web to allowing you to make authorization decisions in your API as we'll talk about in a second or a few minutes all right which token type is right for you depends on your perspective is your if you're a performance engineer you're like yeah self-contained tokens if you're a developer self-contained tokens if you're security Specialists you're going to be like oo reference tokens look pretty awesome because they have great security properties your developers will probably dislike you very much but that's the trade-off you have to make security versus performance in reality it's not that complicated in reality this is often a paper comparison like yes in theory reference tokens have great revocability but it only matters if you have an automatic revocation process if your revocation process is manual like a user detecting abuse on their banking app and they have to call the help desk and at the help desk they're going to tell like yeah I want you to revoke my access token the helpes person is going to be like what I have no idea what you're talking about trust me I've been there I called my bank to tell them to revoke tokens and they were like what um until I got to speak to a developer who actually knew what this was about so if that process is manual and it takes longer than a lifetime of an access token you don't need this because you can always revoke refresh tokens and and poof the problem goes away anyway but if you have an automatic revocation process anomaly detection abuse detection something automated it says like this is weird bam revoke access token then this might matter in practice just a couple of guidelines right here so the performance impact is there token introspection is often not supported in SAS applications so if you have a an out zero that's running as a s somewhere God knows where they don't support reference tokens as in they don't want to deal with you token in respecting the whole time they don't want to offer support for that so they're like yeah yeah we don't care you get self-contained tokens or you can go home that's basically what the the policy is there um also means reference tokens are often used internally if you can do token introspection within your own network within your own application it's a lot faster to deal with that and a lot more capable all right reference tokens are easy to revoke before they expire only relevant I would say if you have an automated process otherwise if it's manual it doesn't matter then f focus on revoking refresh tokens and um they both have limited lifetimes which means that if you can keep your lifetime short enough if your access tokens are limited to 5 minutes or 10 minutes of Lifetime after which you have to use a refresh token then maybe that window is acceptable for your use case if you're building an online shopping application I can imagine that 5 minutes of ABS is not great but also not the end of the world if you're building a bank different story and that's why I can't give you one recommendation it all depends on what is acceptable to you and what you can Implement in practice all right and that brings us to the final step which I conveniently put in one slide just for easy access how do you make authorization decisions with access tokens and that brings us out of the realm of oout and into the realm of API security which also puts it a bit out of scope for this session because it very much depends on how you want to make your authorization decisions some guidelines step one the client sends you an access token that's the premise we have here whether that's a access token from an authorization code flow or an access token from a client credentials flow doesn't matter it's an access token issued by the SDS what do you do well it depends on the type of token sometimes you have to implement support for both types sometimes you can be assured that it's a self-contained token or a reference token but it depends a bit because self-contained tokens you verify the signature the issuer claim the EXP and mbf claims these are important and with introspection you introspect the token and then you check the active claim but at the end of this step your API logic your authorization logic has a set of claims doesn't matter where they came from they have a set of claims that have some specific claims you can rely on and maybe some custom claims as well the next step is making some API specific claims depends on what what you're using if you're using out zero for example every token contains an audience claim who is this token intended for and that contains an identifier of the API so we check like is this identifier me because if the identifier says calendar. google.com and your gmail. google.com you can throw it away like that that's not my token go away there's also an O spec called resource indicators which allows you to compartmentalized access per API in a flow it's it's a bit more complicated but that's what it does and also uses this audience claim it's a jot reserved claim has a specific meaning if it's present if you rely on it you have to check it then we check more generic claims as in generic Scopes not object level access control but we call that often function level access control like Hey we're trying to delete a review does the client have the authority to delete reviews maybe they do maybe they don't a scope would be a good indicator in the token if the application uses Scopes if the delete reviews scope is there then you can grant access to this functionality otherwise you want to skip it that's essentially what this means and then the fourth step it's very easy for me to put on a slide but that's where everything gets screwed up usually when authorization comes into play make specific authorization decisions object level authorization or even object property level authorization if you look at the API security top then these problems are known as Bola or Bula because I don't know why Bola means broken object level authorization and then recently they added Bula broken object property level authorization because you can have authorization up down to specific fields of objects that needs to be enforced how do you do that well it depends on what you're building I can't give you a specific answer to that it all depends on what you're building you might want to check the Su claim containing the identifier of the user if I want to delete a review maybe it's a good check to check if I'm the owner of that review check my Su against the user or the owner or the author of that review and make sure it matches you can check uh customer IDs or tenant IDs if you have a multi-tenant application you can include a custom claim in your tokens that says like customer ID is seven and if you want to delete something from customer 9 the response should be like go away bad user and Report that as a security vulnerability or security uh event you can also have things like client IDs if you have a client credentials access tokens there might be a client ID in there you can be like yeah this client is not really supposed to access these features I'm going to deny access or allow access or whatever and this can go as far as you want you can include roles in your tokens you can include specific permissions you can push this as far as you want um to you uh related to your specific application all right all right let me show you a quick example well I've already shown you but I didn't mention it here's the restorate API and here's how we enforce the use of Scopes in the request again middleware that resource server middleware that I use to verify the signature on the token has a feature to check if the token contains the right Scopes because that's how you often Implement authorization and to access the users reviews you need the read reviews scope before that is allowed that is one use case of implementing that and then in this case we're fetching reviews for a specific user and that means that we're going to filter the actual we're going to find the user based on that Su claim in the token we're going to use that to retrieve the actual internal user and then we're going to use uh that user to fetch reviews for this particular user that would be object level authorization implemented right here like I said heavy lifting is definitely done by that Library liary which you will find for other languages as well so spring has one net has one you will find this for most languages because it just consolidates a couple of features into a nice usable interface all right that 180 Minute Timer is down to 7 so time to wrap up time flies by the way when you're teaching which is uh awesome I hope it flew by for you as well um you're probably exhausted which I can fully get um trust me I've I've been doing this for a while I know how intense it gets the thing is the session is called introduction to O Out and oidc because this is just the beginning this is just understanding what these things do what they can do um where some of the pitfalls lie how you secure your flows against best practices but there's so much more as in I can literally talk for three days straight about these topics going into to excruciating detail on how these things work and what kind of a security requirements are come into play how you want to handle that where can you focus if you want to learn more look up the stock if you're dealing with web front ends like some people said like yeah I've been playing around with react applications watch the stock seriously um it's not good let me summarize it as one word it's not good uh there's a slide in there so are we screwed as a question and the answer is yes and then the the last five minutes focus on the idea of the solution and then you can find plenty of other resources actually diving into the solution that's one thing the second thing is there's a whole bunch of additional oout specs like I said oout is being used in highly secur to sensitive environments these days ealth Banking and some of the properties of oart are not that great for banking applications like having that authorization request with all these parameters malicious users can be like yeah I'm going to change this one into that and maybe modify you don't want that as a client you don't want a user messing around with your parameters so that's not good and that's why we have things like um pushed authorization requests where you can send your data to the STS in a back Channel and then just use an ID in a front Channel or it's par that spec or jar j Json web token secured authorization requests not to be mistaken with Java jars it's a o jar and that jar basically instead of having all these parameters puts them in a sign jot to send through the front Channel and there's a whole bunch of these additional specs that take o out to kind of the next level to high secure o out which will never be part of O 2.1 by the way because they're new features and O 2.1 is just a consolidation of best practices so it will always be an n and end story resource indicators is about compartmentalizing apis highly relevant um is has been in RFC for a while now and is starting to see adoption in uh many implementations so look into that one um we have a pushed authorization requests par we have um Jason Rich authorization requests raar seriously abbreviations all the way we have the jar speec which is about Json web token secured authorization requests we have a Fai profile which used to be Financial API uh security profile like specific configuration requirements for financial apis and then ealth started using that so the financial API abbreviation didn't really make sense so we still have fappy but it doesn't mean Financial anymore it's just fortified apis is the best we came up with I have to describe fafy as an abbreviation but that's essentially um just a few pointers of how far this can take you all right if you're like holy crap that's a lot I have no idea how I'll ever figure that out and if you kind of like the presentation here I'm also running an oout course I did one a few years ago and I'm running a new live online online course so I'm going to be teaching online for four weeks um not not fulltime trust me uh but two three hour sessions a week for four weeks so that's a lot of hours on o out we're all going be going to be diving into all of the details of stuff I skipped here plenty of examples in the same style as this one so if you like this one check out the online course that's coming up it starts mid November so you still have some time to figure out if you want to join that or not all right let me wrap it up in 3 minutes which kind of works out because my conclusion slide has three takeaways which is just a subset of what we talked about but the three most important takeaways number one o out is about allowing a client to access apis most often on behalf of a user most often there's going to be a user involved somehow to make that happen but we also have that client credentials Grant where there's no user involved so it's between brackets that's what o does remember that by the way the client credentials flow only exists for o not for IDC that's a very good tell if somebody comes to you like yeah we're running open and de connect with the client credential flow that's a good way for me to tell if I'm talking to a new customer like yeah you need some help because these things don't M mix and match because oidc is all about user authentication oidc has nothing to do with API access nothing with o nothing with access tokens or most almost nothing it's all about user authentication and client credentials there's no users so there's no user authentication and then finally user facing applications the best practice for that those kind of applications unless you're doing something really specific is the authorization code flow with Pixie and I know this condenses three hours into three takeaways which is not great but I guess doing a 15 minute recap of the last three hours is also not very much recommended uh you can review the slides there's a whole load uh whole bunch of text on the slides for for you to review later on you can grab them from my website from LinkedIn um so they're not that hard to find so do that I recommend that to you with that I want to thank you for being here um connect with me on LinkedIn or masteron if you want to um you can connect with me on Twitter I'm still there but I don't open that in reality so uh good luck with that but um LinkedIn and madon are definitely active um or I'll follow up on that and make see if you want to join that course in November and otherwise thank you for being here if you have any questions I'm not going to run away just yet so you can come up to me after the talk and we can fles it out right then and there and otherwise enjoy the rest of the conference I'll be back on Wednesday to talk about API security for a bit um shorter session 50 minutes but still relevant all right thank [Applause] you

Channel: Devoxx

Views: 9,917

Keywords:

Id: ZuQoN2x8T6k

Length: 163min 45sec (9825 seconds)

Published: Tue Oct 03 2023