OAuth 2.0 and OpenID Connect in Plain English! - Nate Barbettini - PADNUG

everybody thank you for having me my name is nate barber teenie and i work at a company called octa down in San Francisco I don't get to say down in timber Cisco very often I'm normally normally south of it I'm super excited it's my first time in Portland I'm super excited to that you were having me here to speak at your Meetup I'm giving a talk called OAuth an open ID Connect in plain English this is not as boring as it sounds I promise but before we get into that I just wanted to mention that my twitter is up there I'll tweet the slides and and the stuff out from this talk right afterwards so you don't have to worry about like taking pictures of the screen if you don't want to I'll put all the slides on Twitter you can follow me if you want more more info about this type of stuff security and dotnet asp.net is what I kind of talk about a lot and also the team I work on at octa tweets under a talked to dev so we treat a lot of like security related to interesting stuff there as well okay so what I want to do is I want to try to break down oh authen open ID connect which are two protocols that are typically very confusing to understand just as a show of hands who here has ever worked with Oh auth or open ID connect in some way oh no all of you okay almost all of you anybody here consider themselves like an expert on our open ID connect that guy doesn't count because he wrote the book all right really okay so I'm not an expert on it either I am a security layperson who started working in the security industry a couple of years ago and found this extremely confusing and then tried to try to understand it and my process of trying to understand it ended up being a useful thing to talk about because it turns out that a lot of other people were confused not just me so I want to start with some history of these protocols and help maybe help you understand why they're so confusing and help you break down how they work and understand them a little better so just to acknowledge like I said there's a lot of confusion about these protocols online if you've ever Google something like how does a auth work or what is open ID Connect I'm sorry you probably found some really confusing stuff and you probably wanted to tear your hair out what you most likely found is a lot of the stuff that I found which was a bunch of articles that talk to you about the protocols as if you already know everything about them so using all this really dense terminology and jargon but if you're trying to learn this stuff for the first time you have no idea what they're talking about so that's really really confusing and really frustrating and there's like a really steep learning curve to a lot of that jargon the other thing that you'll find is just completely incorrect information like bad advice so you'll see like one dudes blog saying you're supposed to use OAuth like this and then like the top answer on Stack Overflow says that guy is 100 percent wrong you should never do that that's the worst thing you can do you should totally do this other thing and then like somebody somebody else says that they're both wrong so that's really confusing and frustrating as well these are all the things that I found when I tried to learn this for the first time so what I want to do is like I said go back in time a little bit go through some history about these protocols and I found that kind of a useful exercise to understand why they work the way they do and that iluminates as well a little bit of why there are confusing in the way they are but I'll get to that in a second so let's imagine we jump in a time machine and we take our time machine back to like 2007 that is more than 10 years ago now and that's like 42 Internet years ago it's a really long time ago so way back in 2007 just like today web applications and websites had to handle a lot of different like identity or security related stories or use cases you had what you might call like a simple login situation where you just have like a form that takes a username and password looks it up in a database somewhere hopefully you're like hashing that password not storing it in plain text you know logging in somebody knows what I'm talking about that's kind of like your simple login sometimes that's called forms authentication and that works really well with like forms and cookies usually there's also a use case or a story around doing single sign-on between multiple applications a one account signing into multiple systems or federating across systems that's usually done with a protocol called sam'l anybody here worked with sam'l a couple of sam'l did you have fun working with sam'l anybody like it not really tends to be really really heavy and very XML II which if you like XML iam it's probably great for you but not everybody does but around the 2006-2007 timeframe there were a couple of new use cases new new stories new devices that came on the scene that didn't quite fit into these buckets really cleanly so a big one was mobile devices so for the first time we had mobile apps a whole new category with native apps that weren't websites so like cookies didn't really work really well but they weren't they also didn't even necessarily show a web browsers but like you couldn't do sam'l very well either so that was a new category and then there is this other thing that some people were kind of thinking about called delegated authorization which also didn't really have a good solution back then at the time now that fourth one is actually what I want to dig into first so I want to dive into delegated authorization I promise that it's not as boring as it sounds it sounds super like dry and academic but by looking at delegated authorization we'll understand where the OAuth protocol came from originally and then we'll talk about it kind of how it evolved but if we look into this thing called the delegated authorization problem the most academic standing thing of course but this is actually a really simple problem statement that we probably interact with every single day and maybe you didn't even realize it but this is the idea that I have my data in some website or some application over here and I want to let another application have a little bit of access to it not very much just a little bit of access to it in in some standard way and if you think back in like 2007 there wasn't actually a good way to do this today you probably have a million times clicked through that screen that pop-up that says you know yada yada is trying to get access to your Facebook account it's going to give them access to your birthday and your public profile but it won't let them post on your behalf and you click accept or deny who's seen that screen before probably clicked yes to that a million times right and now you have like Farmville connected account a million times so that's a really common pattern now and we take that for granted but that pattern didn't exist like ten years ago that pattern just a spoiled surprise that pattern is the OAuth protocol but let me get there so back in back in that timeframe 2006 2007 there were not any good ways of solving the problem they were just bad ways of solving the problem so this is kind of an infamous screenshot from the early days of Yelp where Yelp tried to solve this problem but they did it in a not-so-great way the thing that they did was at the end of their registration flow they did something that was fairly common kind of normal they said hey you just signed it for Yelp that's great you probably want to invite all your friends to also sign up for Yelp right so we you know let's email them an invite code because that's exactly what all your friends want to get from you right so that but that's like fairly normal a lot of sites do that right the way that they implemented that though was they said okay give us your gmail address cool give us your Gmail password just in case you're just in case you weren't clear what they were actually asking for they said the password you use to log into your Gmail email not the password that you just set up for Yelp so they said okay we'll go log into your Gmail account for you we'll grab all your contacts send them all an email then we'll logout pinkie-swear we're going to throw away your password not do anything evil with it but that's cool right and it's not cool of course that's like horrifying in in terms of the security implications it turned out that Yelp was like they're a fairly reputable company but back then they were just a start-up like who knows if they were doing anything right so this was a really bad way of doing bad way of doing things I would not recommend you using this pattern to to connect to someone's Gmail account but I'm not trying to pick on Yelp too badly there just didn't have a good way of solving this problem back then now we have a great way of solving this problem it's called the OAuth protocol just as a side note this pattern is still used by one specific type of industry one specific type of application and it's even still used today and it drives me crazy anybody what banking yes yes anybody here use like mint or wealthfront or any of those like financial dashboard apps they always say we need to connect your bank accounts so give us your real bank account you know login your real bank account password and we'll login for you and we promise we'll keep this secure it drives me crazy the banking industry is the only industry that has not moved to using something like oh ah 'the for doing this about three months ago I heard a rumor that apparently some bank was gonna do OAuth for the first time with mint which is crazy because that's like the industry you hope would have the most security but it's terrible anyway back to the main topic so instead of doing something like this here's what you could do instead here's how you would use a protocol called like ooofff specifically OAuth 2.0 in this case to solve this problem in a much better way and I'm just going to use the same exact problem statement because it is a really good way of kind of illuminating the issue so let's say that you want your users to be able to finish their registration on Yelp and connect their Yelp account to their Gmail accounts so that Yelp can get maybe just just their contacts email addresses we don't want to have like readwrite access to their contacts we just want to have read-only access we just want to get download their list of contacts and that's it so now that since the internet kind of adopted ooofff 2.0 has this big standard that everybody uses we can do this in a really standard way I'll show you how it works what you would do is you would start with a button on your application we'll just keep using Yelp as an example and say on yelp comm there's a button that says something like connect with Google or authorize with Google user clicks on that what happens is that they're redirected over to Google specifically they're redirected over to accounts.google.com which is something called an authorization server else I'll mention that in a sec but over on accounts.google.com now they are asked for their their Gmail email and password but at least they're more comfortable giving their gmail password to Google because they're at least giving it to the right the right people right they're not giving it to Yelp they're giving it to Google staying within the Google security system after they authenticate after they log in then they're given that that prompt that I mentioned before that's pretty common on the internet now that prompt that says are you sure you want to allow application XYZ Yelp to access these things your public contacts your public profile your contacts whatever whatever the application is asking for and the user is explicitly given the chance to click yes or no you know accept or deny let's say the user clicks accept if they click deny then we're done we don't have any more interesting things to talk about but if they click accept the user is redirected back over to the original application back over to Yelp to a special place on the Yelp application called a callback or a redirect URI and then a little bit of magic happens behind the scenes which I will explain in just a sec but the Yelp application gets something called an access token that is stamped or or yeah stamped embedded with the information that the user had clicked accept or yes to that prompt so the access token then becomes the way that Yelp can go back to Google and say hey Google normally you would not give me Nate's contact list but I have this access token that proves that proves that Nate said yeah it's okay for you to have my contacts so Yelp can go up to some API maybe contacts on google.com say please give me Nate's contacts here's the access token proving that I do actually have permission to do that and then Google will say okay normally I wouldn't let you but yes Nate gave you permission here's Nate's contacts or whoever's contacts so this is the whole this is the whole thing at a really high level this is exactly how the oauth 2.0 protocol works it's a protocol for exchanging this type of permissions information between systems if one system if both systems support the OAuth 2.0 protocol then the application can say I want these permissions in your system and the system on the other side will say ok let me make sure the user is okay with you having those permissions user says it's ok sure here's an access token that says the user said it was ok that's the how the whole thing works now this is super high level because I didn't actually use any of the real oo auth terminology which is where the learning curve gets kind of steep sometimes some of the terminology is kind of dense but what I'm gonna do is go through this flow this diagram like five more times you'll get really tired of it and I'll kind of add in the terminology step by step so you can see how all these pieces work together so let's add some of the terminology in right now in the oauth 2.0 protocol we have some names for stuff that we already have names for but they just renamed it for some reason so instead of users we talked about resource owners but a resource owner is just the user behind the keyboard who can click yes to that prompt who can say sure I allow this permission to be given a client in this in this ooofff land is the application that needs that access in our example that was Yelp the authorization server is the server or the system that owns the users identity or owns their account so accounts.google.com in our case is where the user can log in and actually give that that permission the resource server is the system that actually holds the data that the client wants to get to so in this example we were saying that the client Yelp wants to get access to the users contact information that's some somewhere in Google but it's actually a different API than the authorization server that's like the contacts API so sometimes the authorization server and the resource server are like the same system if it's like a small system but a lot of times they're split out I'll show you how that works when the user clicks yes or except or allow to that prompt they generate the authorization server generates something called an authorization grant that authorization grant is just a temporary token or temporary thing that proves that the user said yes to that prompt and that sent back to the client but ultimately what the client is after is not an authorization grant what they really want is an access token because that's the thing that will allow the client to go make API calls to the resource server and say hey resource server I want that data and I have this token proving that I have access to that data so the client has to go from getting an authorization grant to getting an access token and I'll explain how that works in just a sec but this is some of the terminology this is kind of the based terminology you need to understand how this works let me go back through that flow and I'll show you how each one of these pieces work together so we start off here on the client which is Yelp and we have the user presumably sitting in front of the keyboard sitting in front of the screen that's the resource owner they have an account on Yelp and they also have an account in Gmail with some contacts that's the data the resource that Yelp wants to get to when the user clicks on that connect with Google or connect to my Google Account button they're redirected over to the authorization server which is accounts.google.com and when I say redirect I mean like an actual full page redirect the URL you know window dot location is changing we're doing a get request moving the browser over to some place on accounts.google.com along with that redirect we send along the client sends along some information some different parameters like where we need to end up at the end basically where the authorization server needs to redirect back to at the end that's what's called the redirect URI and then also what type of authorization grant the client wants to have at the end for now we'll just talk about one type of authorization grant called a code which is like the simplest one because the client is asking for the code response type or the code grant this is commonly referred to as the authorization code flow because that's what the client is getting at the end so by sending along those parameters at the beginning this request is kind of set up and sent over to the authorization server and then the authorization servers job is to actually make sure that the user is okay with granting these permissions and allow the user to click yes or no prompt them for consent are you sure you want to allow Yelp to have access to this stuff that they asked for assuming the user clicks yes then the browser is again full page redirected back over to wherever the client asked to be redirected to the redirect URI and along with that redirect URI along with the get request the authorization code is sent back to the client application usually in the form of a query parameter so that's just question mark code equals and the authorization code now I mentioned that what the client really wants is an access token and right now we don't have an access token we have an authorization code well it turns out all the client can do with the authorization code is make one more request back up to the authorization server and say hey you just send me this authorization code but what I really want is an access token so here's the code can I exchange it and I'll give you the code you give me an access token if the act if the code is still valid if it hasn't been like tampered way that are made up or something then the authorization server is going to say cool yeah I see that I gave you that code here's your access token in exchange and then what the client can do now the client has what it really needs the access token and it can go make a connection to the resource server call some API on the resource server and say hey contacts don't Google com I want to grab this you know Nate's contacts here's the access token that proves that Nate said yes you can have access to those contacts all right everybody feeling good so far does this make sense question over there is that encouraging spamming uh yeah it probably is but you might be it so well it doesn't just have to be giving Facebook your contact list we're actually not talking about authentication yet we're just talking about authorization here we will talk about it right but actually we're not both is actually not for authentication it's misused for authentication but it's it shouldn't be used for authentication actually I'll talk about that when we get to open ID Connect that's that's a really good point you probably shouldn't but there are there are times where you would want to be able to exchange a little bit like allow some system have to have a little bit of access to your data somewhere else maybe for you you would never want that to happen but you can imagine situations like let's say that I want I have a bunch of photos in my google photos and I want them to be printed at Walgreens instead of downloading them all and putting them on a flash drive and going over to Walgreens and plugging it in maybe I could allow Walgreens just to have access to my google photos or maybe just one album of my google photos so that they can print them online I don't know and maybe you like if you're really privacy and security conscious maybe you still wouldn't want to do that but the idea here is that you could at least have a little bit of control over it instead of saying you have full access to everything in my Google account at least Olaf gives you the ability to scope it down and say you just have access to this little thing here but that actually raises a really good point because I haven't talked about how we can ask for exactly the permissions that we want so Olaf is all about authorization exchanging permissions but authorization and permissions are only good if you can make them granular right you don't want to be able to cut it to your point you don't want to have the only options is no access and full access because that's kind of useless as an authorization mechanism so in the OAuth world we have this idea of scope which is just a fancy way of saying the specific types of permissions that I want and the flip side of that is this idea of consent where the user whatever permissions the application asks for the user has to explicitly grant so there's no there's like kind of no funny business in the sense that the application can't just say like I want this little bit of access and then actually get a ton of access did you have another question I'm not suggesting that ya know to be clear I am not in any way advocating that social networks are benevolent or that you should trust them with all your data because I don't think either those statements are true yeah so Oh aww thats confused with social authentication a lot ooofff is much more than social authentication although that is like the main probably the main thing that most people see it in that context so a lot of people think that oh ah equals Facebook or equals social social login or social networks that's kind of unfortunate I think because it's a pretty powerful protocol that's used in many other areas not just not just logging into Facebook or whatever a good example is what I hope will happen which is mint and the banks can agree that they can both use OAuth 2.0 and then I can say that I can connect you know in a read only way I can connect mint to my banks so they can see my you know my account balances but they don't have like right access to my bank account they can't make transfers or something which is not possible today by giving them my full bank password right so it is true that oo auth is unfortunately discussed a lot in the context of social networks and Facebook and stuff and I am using Google as the example here just because it's a really like easy to understand relatable example but it is used for much more than than social networks so I mentioned that the way that we can ask for specific permissions in ooohs is by this idea of scope and the scope is just a string it's just a string that has some label or some meaning in the authorization server so this might be in Google's case there's a scope called profile which means that you're asking for permission to just read the person's public profile there's a scope called contacts I think it's contacts not read-only which gives you read-only access to the users contacts there's a separate one called contact stop rewrite that gives you read/write access to the users contacts so you can imagine that if you are building an integration against Google or you're building an iteration against any ooofff anybody who speaks ooofff the first step is you'd go to their documentation understand what all the different scopes you could ask for are and then figure out for your application for your use case what do you actually need what scopes do you actually need to ask for in this case in our fictional example Yelp needed access to my Google contacts so the Scopes that they may ask might ask for our select a profile contacts that specific list of scopes that Yelp is asking for is sent along with the authorization request with that initial request over to the authorization server so I send along some parameters for redirect URI for the response type what grant type I want and also what scopes I want is just like a string a full long string with space delimited list that list of scopes is then what's used to build the consent screen that the user has to click accept to so yeah that's a great question so know there are in the OAuth 2.0 spec there is no standard list of scopes or standard naming for scopes all it says is that it's a string which is kind of annoying because if you are implementing your own like setting up your own implementation you would probably want some guidance as far as like what the scope name should be I'll talk a little bit more about that when I get to open Eddy Connect totally it does right yeah so this is something that what what scopes are possible what scopes are available and what they are called and what they mean is all something that's in the realm of the authorization server so Google in this case has a long list of scopes that you could ask for as a client application you don't have to worry about like how its implemented you just say okay for my app I need access to your Google Drive or your Google photos or whatever I have to find the Scopes that apply to that thing whether I need you know read-only access or readwrite access or delete access or whatever that's all buried in Google stock somewhere and then yeah you're right on the on the authorizations server side it's totally up to the authorization server to be able to like map a scope name to some friendly description that they're actually going to display to the user yep you're absolutely right yep it's that's one of the frustrating things actually is that there isn't a common naming so if you look at like Google's documentation and Facebook's documentation they're totally different which is good and bad because the types of stuff you can do in Google are very different than the types of stuff you can do in Facebook so it makes sense to have different types of scopes if you look at Google's Doc's all their scopes or most of their scopes are long like URI style strings so it's actually like HTTP something something something Google slash account slash read / write or whatever which yeah yeah definitely so one of the one of the trickiest parts of setting of kind of doing this for the first time or trying to get this working is trying to make sure you have all the right stuff in that initial request so I'm only showing out of a subset of it you need redirect URI you need the Scopes you need the response type you also need client ID and some other stuff I'll show you an example of what the full thing looks like but I'm keeping it simple for now so let's say that let's say that my fictional application requested the profile scope and the contact scope and let's say that google rendered a message to the user saying are you sure you want to allow Yelp to access your public profile and your contacts and the user click yes the browser gets redirected back over to the client application with an authorization code that authorization code carries with it the the proof that the user clicked yes to that to that screen and click yes to those scopes and then when the application exchanges that for an access token that access token itself is scoped down to exactly those operations or exactly those things that were requested at the beginning yeah that's a fantastic question so it looks like we're doing a bunch of extra work right it looks like I'm I got an auth code and then I go immediately back and exchange it like why not cut out that step that's a fantastic question and an alux answer in just a second but what I wanted to point out was that when the app the client application goes and talked to the resource server using the access token that we got through this whole flow even if that access token is totally valid hasn't expired all that good stuff but the client application tries to do something that it wasn't originally scoped for even a perfectly valid access token will fail because the author is the resource server rather the resource server is going to check a number of things when it cut when a request comes in using an access token it's going to check of course that the access token hasn't been my totally made-up or forged or something it's gonna make sure it hasn't expired it's still good but it's also gonna make sure it's gonna look at the original scopes that are stamped into that access token and check alright your scope was profiling contacts why are you sending me requests to like delete you don't have that scope and it would return an error so scopes are the way that ultimately end up restricting that access token and what it's allowed to do and if in for some reason the client application wanted to get more more permissions maybe they initially just wanted to get profiling contacts but later they want to be able to you know delete something or send an email or whatever that would require a new scope they would have to go back through this whole flow request a noose of longer set of scopes go back to the authorization server the user would have to consent to that new one get a new code get a new access token and then that new access token could go do more stuff does that all making sense so far all right so you had a great question about why are we doing this extra exchange step why don't I just get the access token right back from the authorization server why do I need to do that well there's actually a really good reason it's a security reason to and understand why we need to talk about the difference between a back channel and a front channel these are not strictly oo auth terminology this is more like network security terminology I guess but when we're talking about network security we can differentiate different types of requests based on how secure they are different types of request channels I guess based on how secure they are so let's imagine that you're let's say your back end code your dotnet or Java code or whatever makes like a post request over HTTP to some API somewhere that's pretty secure encrypted connection using HTTPS you know it's your back end code so nobody's going to be able to intercept it or whatever not going through a browser that would be what we consider a back-channel it's really secure now contrast that with a front channel which is something like a browser browsers are pretty secure but they're not totally secure browsers have this annoying loophole where they actually have to render stuff to the screen so technically if you are transmitting something through a browser like in the you know somewhere in the in the URL in the query parameters of a URL somewhere in the HTML of the page technically if someone was just looking over your shoulder or they have a weird toolbar installed in the browser or something they could they could sniff things like what's on the page what's in the URL bar things like that so while browsers should be using HTTPS and all that good stuff there's still some loopholes where you could potentially intercept something that was sent through a browser so you'll notice that a number of these steps involved page redirections where we're doing a get request put it putting the browser onto a new location which loads a new page and we can send information between different systems that way using just corey parameters we can put something in the in the query parameters of a request or in the post body of a request and that goes through the browser it should be over HTTP so that should be secure but if someone could intercept those query parameters or they intercept that post body or something they could potentially grab something like your authorization code so you'll notice if we take a look at this flow again all this stuff that's solid lines here are front channel requests so the initial redirect over to the authorization server that sets up all the all the stuff the redirect URI the response code the Scopes all that stuff that all is just a get request that has query parameters that's how we send all that stuff over to the authorization server and technically maybe somebody could intercept that some weird browser plugin could intercept that or whatever malware on the machine could see that but if somebody saw that request it would wouldn't really be a whole lot of harm done they know that we're asking for these scopes they know that we want to end up at this redirect URI but like we're gonna end up there in a second anyway it's not going to be really any secret information you'll notice that the authorization code also comes back over a front channel that's just a post or a get with something in the query parameter or something in the fragment so that also could technically be intercepted maybe someone could grab that authorization code and try to like get an access token with it before we get an ID that's token with it maybe technically but the very next step that happens happens not on the front channel but on the back channel so when the client application gets that authorization code and it has to go back up to the authorization server to exchange it for an access token that exchange step happens on the on the back-end code happens on a back channel so that's like a post request from Yelp servers up to Google in this fictional example very true so it is very important to note that there's also a secret like a password that goes along with that I'll show you that in a sec when I show you like the full raw request but there in addition to the authorization code which technically maybe could be seen somewhere in the browser there's also a secret value what's called a client secret that's sent up with that exchange step that proves that that application is who they say they are and we don't ever send that client secret over the browser which for for security reasons you'll notice also that the communication between the application and the resource server is usually also only on the front channel so we keep that once we have an access token we try to keep that really private keep it only on the server and do our best not to let it be on the client anywhere there are some exceptions to that which I'll talk about in a sec but this is what the initial request would actually look like this is like the full version of the initial request this is what if you look at the destination URL of a button like the facebook login button or connect with Google button or whatever this is what's what it would look like it starts out with some URL on the authorization server that's accounts.google.com slash something something something and we have to send along a bunch of stuff to kind of bootstrap or set up the request I mentioned already the redirect URI and the Scopes and the response type there's also a client ID which you mentioned before the client ID is just a value that represents this particular application this client as opposed to some other clients so the authorization server knows who's calling who's who's starting this request and there's some other stuff you can send along here sometimes you send a state which is just a value that goes all the way through the Anson comes back the other side question no I didn't I didn't skip past the implicit flow because I hate it I just skipped past it because I haven't gotten there quite yet but I'm really glad you asked because we will talk about the implicit flow so this I wanted to show you one other things here if I can switch gears and it doesn't hate me too much all right so if you have ever setup any type of integration with Google for example then you've probably seen this this this panel that lets you set up a set of credentials for your application anybody gone through this before maybe okay so this is the same state you got to do the same thing with Facebook or Twitter or any other Roth system that you're connecting with even non social network ones but the idea here is that you have to do a one bit of one-time setup on the authorization server before you can kick off one of these requests you have to create what's called a client ID and a client secret the client ID represents the fact that you are connecting Yelp or somebody is connecting to this authorization server and then the client secret is a value kind of like a password that you keep secure on the server and you never give out to anybody because that's what you that's what is used to authenticate or prove that connection when you go do the exchange step so I mentioned before somebody asked a question about all the different stuff you have to set up in the request just to kind of get the first request working and that turns out to be like one of the hardest parts of doing OAuth correctly it's just like really hard to to get it working the first time so I built a little tool that can help with that it's called the OAuth debugger if you want to just hit like go off debugger comm what this tool lets you do is you punch in like the the authorization you that the authorization server uses which you can find in their documentation you punch in your redirect your I you put your client ID in there you put the Scopes in there all the stuff you need and then it creates the correct URL for you and lets you try it out I built this only because I have been doing it by hand like so many times I got so frustrated that I was like there's got to be a better way to do this so I built this little tool but I'll use it to show you kind of what it looks like so you imagine that we set up a request against the Google authorization server just the same exact type of request that I was showing in the slides let me see if I can make this bigger alright so this is the base URL that the Google authorization server uses it's different for any other olaf authorization server and i have a client ID that i set up a long time ago for demo purposes that's my client in google let's ask for the profile say email scopes now profile contacts just like the just like the example and then I say that I want a authorization code back that was the response type I asked for and it's going to come back in the query string this is the full URL that you would need to generate in your application to make that work you can copy it if you want and then let's try it out if I didn't make any mistakes no contact is not actually the real scope that Google uses let's just say profile you can see how this will work so it didn't actually ask me to login at Google because I'm already logged in in this Chrome session but you can imagine what it did in that 200 milliseconds or so it actually redirected my browser over to Google knew I was already logged in so it immediately redirected back and I got an authorization code this is what my authorization code looks like now then of course the next step is that my client my application would need to take that authorization code exchange it for an access token and then it could make some calls with that access token I can't actually do the exchange step here on this tool because then you'd have to give me your client secret and that would be really bad so I'll show you in the slides instead yeah ah great question I glossed over that sorry I've already logged into Google and I've already done this demo before and I've already clicked except to that scope so he didn't ask me again if I did this in an incognito window or on an another Google account it would have asked me another Google account not an incognito window or I could go into my account and disconnect this application and revoke it or whatever and then track it you should not store the authorization code on the server side well the reason I say you shouldn't store the authorization code is because the authorization code is a very short-lived and should only be used to go get the token if it's load-balanced and one server doesn't know about the code but another one does that's a very interesting edge case that I would love to talk about with you afterwards that that's I think the short answer is that shouldn't happen because you should all the server should know about it behind the scenes instances are you talking about instances of the client or the authorization server are you are you running are you running your own authorization server gotcha gotcha that's that okay I understand the question now that's a good question actually this is the guy you want to talk to you because I know more about it from the client side he wrote the book on doing it from the server side so mr. Aaron por aqui I will introduce him to you afterwards okay so I show this already in the demo in the in the application but basically the authorization server will redirect back over to the client in one of two states either in an error state because the user clicked no I do not accept this permission or maybe you like messed up the parameters in some way and it didn't work like the first time I tried it either you'll get redirected back with an error so you have some error message that you can display or you'll get redirected back in a success state and you'll get the code that you asked for and then whatever state you at you sent along at the beginning then of course the next step is to exchange that code for an access token so that means going back up to the authorization server this is now not happening in the browser this is a post request from the back-end code up to the authorization server on a different URL saying hey okay I get you just gave me this code here's the code here's that client ID that I sent before here's also the client secret that we haven't said before this client secret is what I got when I initially set up my application with the authorization server and that client secret hasn't hasn't left my server I didn't put it in the browser I didn't publish it on github hopefully we've all been there so if if I send all this stuff up to the authorization server and the authorization code hasn't expired or like isn't tampered with or something or hopefully it's not swallowed by a load balancer or something what happens is I get back finally at the client application and get back an access token that access token is just some string in the OAuth spec it doesn't say what format the string should be in or how it should be in some token format or something it just says it's a string the client should treat it as just an opaque value that's a magic value doesn't know anything about it and also some expiration information like how long it's good for things like that now the client can finally go make requests to the resource server with that authorization with that access token rather we use the HTTP authorization I'm gonna get this all tongue-tied the HTTP authorization header with the word bearer and then the access token sometimes these are called bearer tokens because of that word bearer they're basically what's happening is this you can imagine at a high level the clients making a request to some API and it's attaching that token to the request on the API side the API the resource server or the API is responsible for validating the token making sure it hasn't expired making sure that the client just didn't make it up and then also like I mentioned before making sure that it actually has the scope to do the thing that the client is trying to do so if I have a token that is scoped for you know read-only access and I'm trying to do some write or some delete it should say tell me no assuming that all those checks check out then this particular request is authorized it's approved and then if the client needs to make another request this whole thing has to go again we use that same token we make another request and that next request would be approved this could happen you know ten times a hundred times a million times at some point the access token will expire and the client will have to go get another one from the authorization server it turns out it's not too hard to go get another one because we can just go back through that ooofff dance get a new authorization code get a new access token and we have a fresh one that we can go assuming that the user hasn't in the in the meantime rejected my my permissions or rejected that approval for my application okay so we kind of went down into the weeds with the OAuth 2.0 authorization code flow that's what we're looking at there there are some other flows as you mentioned we also have something called the implicit flow which is available if we don't have a back-channel available I was kind of mentioning how that authorization code uses both the back channel and the front channel together the front channel is really easy to pass stuff back and forth through the browser then we use the back channel to just kind of add some additional security to it to make sure that we don't send the client secret over the browser for example so the authorization code flow is a really good balance between the front channel on the back channel the implicit flow is front channel only which means it never has any back channel communication and that's slightly less secure or depending on who you're asking very much less secure because we don't have that assurance of having a back channel connection and we also don't use the client secret but it's available for situations where you just don't have a back channel available and a good example of that would be many times if you have like a pure angular app or a pure react app some JavaScript application that's totally running in the browser you're making requests to an API with it but you don't have any back-end code that's you know rendering the page you don't actually have a good back channel available and so a lot of times people use the implicit flow there the implicit flow and refresh tokens no know Aaron's shaking his head at me it doesn't I always forget about that one I have to look it up every time I haven't really talked about refresh tokens yet but I can later if you're interested there's a couple other flows anybody using the resource owner password flow maybe kind of the resource owner password credentials flow is a back-channel only flow which is usually used it's not used a ton anymore but it's available if you just want to post the users like username and password directly and get a token without going through this redirect back and forth also the client credentials flow is another back channel only flow that's used for like machine to machine communication a lot of times but the first two are the most common uses of OAuth 2.0 on the web just because you asked about it the implicit flow I'll go I'll kind of show you what that looks like real quick the implicit flow looks exactly like the authorization code flow except instead of response code I asked for response type token that means I'm not getting a code back in this redirect back step I'm not getting a code back I'm getting the actual access token directly back which means that I don't have that exchange step I don't technically have that assurance that the the token wasn't intercepted somewhere by someone you know like sniffing it out of the URL but it does help you get around the fact that like in a spa you don't necessarily have a back channel available okay so let's jump back into our time machine and fast forward a couple years we started out in 2007 then say like five six years later this hoth 2.0 thing became really popular it ended up being so popular that it was kind of a victim of his own success in a way as I mentioned before Oh a 3.0 was built for this authorization kind of delegating permissions between systems that's what it was built for that's what the protocol is built around that's what the protocol is meant for but because it was so popular and everybody started using it it became very tempting to also use it for authentication so not just for the delegated authorization stuff but for logging on native apps single sign-on type stuff even just like the simple login the big thing that kind of pushed a wast 2.0 into the mainstream for authentication not authorization was social login so around this time Facebook introduced the idea of the facebook login button which at the time was a kind of a new idea it's like half step inside the single sign-on thing but it's also a little bit of a different thing itself where you have an account with one of the big networks like Facebook or Google or LinkedIn or whatever and you can use that account to log in on other sites where you don't want to necessarily have to make a new password every time you just hit that facebook login button you get access to that new site that's authentication not authorization that's not what auth was originally built for part of the reason why it's so confusing to understand I often read any of the stuff people write about OAuth on the web is because half the time they're talking about using it for the original thing that it was built for which is authorization and half the time they're using it for authentication and talking about it in this context where it's like not really meant to be used now that's that's unfortunately more confusing than it should be and I think Facebook and Google and the big guys who decided to do this kind of share a little bit of the blame for making it more confusing than it should be the reason why I say that Oh Oscar pono is not good for authentication it's not just like an academic argument there's some specific things that we've kind of already talked about a little bit I mentioned that there's no common set of scope names so every OAuth 2.0 implementation is a little bit different the big reason though why Oh auth 2.0 kind of sucks for you for authentication is that there's no common way of getting the users information in a walk 2.00 woth like I said it's all about authorization it cares about what permissions you have it cares about scopes it cares about tokens doesn't really care who you are necessarily so imagine you're building an authentication system somebody logs in to your site you'd imagine that probably the first thing you want to know is like who just logged in maybe like what's their name what's their email address some basic stuff like that but oh I can end point or a part of the protocol that describes getting the users info so when Facebook and Microsoft and Google and LinkedIn and everybody built their social login buttons each one of them built some proprietary kind of hack on top of OAuth 2.0 that you can get the users info on Facebook it was like a slash mean route that you could call with the access token and get some user info with that it looked a little bit different for Google Microsoft called it something a little bit different and when you have a standard that's being used in many different interesting ways like that it becomes really difficult to use and it just wasn't meant for authentication in the first place so just solve that problem some smart people went back to the table and said well this OAuth 2.0 thing is really caught on it's like a big Internet standard now but people are now using it for authentication why don't we just make a new protocol that already kind of takes all the stuff we learn from all 2.0 and just make it really nice for authentication - that's where we got open ID Connect so I said new protocol but that's actually a misnomer Open ID Connect is not a new protocol it's just a pretty thin little extension on top Oh autopano that just adds the stuff you would need for authentication and also tightens up some of the stuff like that scopes can be whatever you want and makes it a little bit narrower so that each implementation is a starts looking a lot more standard so specifically to close the gap for that authentication use case open ID Connect adds this idea of an ID token so just like a las 2.0 we're getting an access token that that can be used to call a pis or whatever but we also get you know in open ID connect an ID token which just has the info about the user their identity information in it and if that ID token doesn't have enough information in it the application wants more for some reason there's a special endpoint called slash user info that the application can call and get more info about the user and like I said it also just standardized some of the scopes and makes the implementations a little bit tighter so that if you have a system that says I support open ID Connect I'm open ID Connect certified and your client is also open ID Connect certified there they can talk to each other very easily and you don't have to worry about some like minor differences in the implementation like you do with OAuth so let me show you what it looks like to authenticate with Open ID Connect now we're actually talking about logging in we're not talking about getting permissions in another system so instead of like authorized with Google maybe it says login with Google pretty much all this flows look gonna look exactly the same because it's not a new protocol it's just ooofff 2.0 plus this little bit of extra bit called Open ID Connect the actual only real difference here is you'll notice a new scope called open ID that open ID scope tells the authorization server if it's an open ID Connect compliant authorization server if it understands open ID Connect that tells the authorization server that this is going to be this is an authentication request I want an ID token at the end of the day not just an access token the rest of it looks exactly the same get an authorization code from the other side exchange that authorization code for an access token and an ID token this time that ID token can then be used by the client application to immediately understand who the user is maybe create a local session for the user put the users information in the local database or whatever makes sense there and then the access token can still be used to go back up to the authorization server or to a resource server somewhere for example to get more of the users information let me show you yeah oh that's a good question um I think that's somewhat up to the authorization servers discretion I haven't tried it with every one of them I know with with Google I think open ID implies profile so you'd at least have to grant access to your public profile in order to do that let me show you an example of what open ID Connect looks like I have another version of this tool called oh I DC debugger open ID Connect debugger which as you might expect does the exact same thing for Open ID Connect so my company octa lets you run an open ID Connect authorization server like in the cloud and totally manages it for you so you don't have to worry about the details of the implementation so I have one of those I have an open ID Connect authorization server running that's custom that's built by me not really by me built by octa and I have set it up with a client ID for this application I'm gonna request the open ID scope and instead of I'm actually gonna use the implicit flow here because I want to end up with the token instead of the code I'm gonna request an ID token and let's see how this works this time I have to login okay so I had to login over at the authorization server once I logged in I get sent back to my application with what I asked for which in this case was an ID token that ID token looks like this it's a long string just like the access token is in the ID tokens case it's actually a very specific type of string unlike oo-wah supa know where the string is just like an opaque value an open ID connect the ID token has to be what's called a JSON web token or a JWT and that means that I can decode it very easily with a tool like JSON web token dot IO blow this one up to so I can just paste this in all it is is that whoops all it is is a base64 encoded JSON object JSON blob so it looks something like this I know that's kind of small but it has some information about me it has like my user ID it has the time I logged in it has the time yet the token expires the authorization server that granted the token some info that my application can understand bless you let's get past this okay anybody here worked with JSON web tokens before it's pretty common yeah especially if you're like in the node world it's really common there a JSON web token like I said is just a base64 encoded JSON object if you take a JSON object serial is that serialize it to a string and then put that through a base64 encode or you have a JSON web token it's made up of three different parts that are separated by a period if you look really closely you can see a period in any JSON web token two periods actually those three parts are a header a payload or a body and a signature so aside from carrying some information some some JSON information JSON web tokens are specifically JSON signed JSON web tokens also carry a signature which is a cryptographic hash of the contents of the token what that allows us to do is be able to verify that the token has not been tampered with even without having to go back to the authorization server to make sure the token is still valid so I can say the token claims to have this signature let me just look at the information in the token and make sure it matches that signature if it does I know that the token has not been tampered with if it doesn't something funny happened somebody tried to mess with the token and it their their role or something like that if anybody's curious about how that signing process works I can I can go into it more but I wanted to show you what it looks like if you decode kind of what I did on that tool just now if you decode just the payload portion you see something like this and that's base 64 encoding it's not encryption so it's not like it's being encoded for secrecy it's just being encoded so it doesn't have any weird characters it's like very you know Network friendly to send over the wire and a header or something like that so it looks something like this you get information about the user when they log in when this token is going to expire things like that and then like I said if you want more information about the user then you can take the access token that you also got through the open ID connect flow and go up and call this special endpoint called the user info endpoint and get some more information about the user and that's usually stuff like again the users name but depending on the authorization server it might also be like their profile picture or whatever the authorization server wants to send you so if we take our time machine from 2012 ish all the way up to today now we can see that things are settling out like a lot better so the way the industry is kind of moving towards is using Open ID Connect as kind of a standard glue a standard protocol for doing a lot of authentication use cases you can use it for like the simple login stuff for single sign-on stuff if you don't want to do sam'l you can use it really well for mobile authentication and then you would still use if you need to do the delegated authorization use cases you would still use OAuth 2.0 that's still the best tool for that job but at least now we're using like authentication protocols for authentication and authorization protocols for authorization now some people get confused because they've probably heard of like both of these things but they've heard that Open ID Connect as newer and so they think maybe it replaces OAuth 2.0 or one is better than the other but I just wanted to stress that these are two different tools for different jobs so if you're doing authentication logging in or letting people login to you that's open ID Connect if you're doing authorization granting access dealing with permissions things like that that's a woth 2.0 and it's fairly common to see both of these used in the same in the same application just for different different parts of the application so they live side by side perfectly fine one does not replace the other if you're doing auth stuff or open ID connect stuff one thing that this can be kind of hard to wrap your head first is what what flow what grant type is the best to use in a particular situation and right now it seems to be the current best practice that for web applications with server backends that can run back-end code that have a back channel available then the authorization code flow is the best way to go that has a really good amount of security built into it ditto for mobile applications you can use the authorization code flow on mobile apps as well you have to use this additional extension called pixie or proof key for code exchange that patches specific vulnerabilities in that only exists in mobile operating systems so you can use that really well for mobile apps I mentioned before that if you have a single page app with no back channel available then you can use the implicit flow and then for like micro services api's things like that you can use what's called the client credential flow to get a token in an automated way so you can make like API calls in the middle of the night or something like that I wanted to show a couple of oh sorry question yeah that's a good questions I don't have an example of client credentials in this deck in this presentation but the way the client credentials flow works is it's just just a post request post to the authorization server with like a key and secret and you get a token back and it is usually not in the context of on behalf of the user it's usually in the context of like a machine to machine communication so you might have a let's say that you have an automated service automated job that runs every night or something you generate a key and secret for that application and then it can go get tokens totally without a user ever clicking yes or authorizing anything just to illustrate the examples that I was just talking about the different like flows if you're used if you're building a web application with a that has a back-end server you know asp.net spring whatever you want and you're doing authentication if you want to kind of pull apart the authentication mechanism or the identity mechanism from the application and not have to have those living in the same application then you can push the login process or the authentication bits over to an authorization server and then just use the open ID connect as the glue between your application and then whatever identity system you're using you see this commonly happens when especially when you have applications that end up being a suite of applications and you need to do single sign-on between them this is exactly how Google does it they have a Council at google.com as they're like authorization server their authentication mechanism and all the different Google products use that and then each application then is setting their own like local session or something that keep track of the user but they're relying on the authorization server to actually do the login and grant those tokens yeah it at the exactly the same place so if you're doing open ID connect and you want an ID token when you do the exchange you post the authorization code up to the authorization server instead of just getting an access token back you get an access token and an ID token at the same time that's the only difference with Open ID Connect that's a good question anybody else have any questions I've been talking for a while yeah it is it is yeah so when when you set up the initial request and you say here's my scopes here's the grant type that I want here's the redirect URI that I want you to come back to that also has to be something that's registered in advance exactly you have to agree or not agree on it in advance the reason you have to do that is just an additional security measure that's so that somebody can't set up like a very convincing phishing site that that starts off the flow but then says no come back over here when you're done and try to steal those tokens the authorization server has to pre basically like pre approve the redirect your eyes that the user will end up on there was another question yeah yeah typically you would have separate client IDs for like devastating prod most likely yeah you could might be able to use the same authorization server yep so we're talking about registering a user account gotcha so unfortunately open ID Connect has absolutely nothing to say about user registration so that would have to be something that's like--that's out-of-band of open ID connect the user has to be registered with the authorization server in some way yes not that I'm aware sign out yeah there is there is let me show you let me skip back a couple of slides let me show you something that's kind of cool so the question was is there a way I understand how we can sign in but what about signing out one sec so I mentioned that I had an author's an open ID Connect authorization server running up in the cloud via octa and that because it's an open ID connect server something that all open ID connect servers have is something called a metadata document or a discovery document this is available on a very specific URL of the authorization server and it's just a big JSON document that has a bunch of info in it that tells you what all the different URLs are that you need to do to use if you want to like start a request if you want to do the token exchange if you want to get user info this discovery document is one of the other things that Open ID Connect adds that makes it a lot easier to build kind of a standard reference implementation of Open ID Connect it's kind of like a wisdom lighter cleaner more hipster it's JSON what this allows you to do is take a client just a generic open nd Connect client pointed at this authorization server the very first thing is going to do is see if it has one of these discovery documents and if it does the client is able to kind of bootstrap itself and understand okay when someone wants to log in I'm gonna hit that authorization endpoint right there now to answer your question about logging out if we scroll all the way down to the bottom here there's something called the end session endpoint and that does exactly what you're asking about that would be if I want to log the user out I want to kill their session at the authorization server I can redirect them through that end session you endpoint and they would be logged out bless you so there's an interesting there's kind of an interesting nuance here because if you are if you're building an application that's using an open ID Connect authorization server for authentication that's that's a mouthful you kind of have you end up having two sessions going on that are tracked separately you end up having a session over on the authorization server like the user is logged in at the authorization server and then you also have a local session in your application that's probably like a cookie or something that you're dropping in the user's browser just like you would with like forms authentication so there's there's some nuance there as far as when the user logs out are they logging out of just the local application or are they also logging out of the authorization server and that it depends because sometimes maybe you have one application and one authorization server and they're basically just the whole the same like application but you also might have like something like Google has where they have all their different applications using the same authorization server kind of for like a single sign-on type of situation and in that case you have to be very you kind of have to think about what if someone logs out does that do you want them to be logged out of all the applications at the same time like killing their session across all apps or you just logging out of this one if you want to log out of all then you would go through that end session endpoint that kills the session at the authorization server level does that make sense okay cool any other questions I know there are a couple other hands yeah in terms of your your wondering if is there a standardization in terms of what data is returned from the user info endpoint if I call that user info not quite that I need to actually be different every time because it has stuff like the timestamp they logged in yeah it it would be they would both both the ID token and the user info endpoint would have information about the user the well the ID token is the ID token isn't like a permanent representation of the user it's not like a gooood that represents the user but it would usually contain something like that so it would contain a user ID yeah yeah so yeah you wouldn't you typically would not store the ID token for a long period of time you might exactly yeah so if you're if you're talking about being able to do essentially like a foreign key between your your system and the identity system then you would you would look for the user ID in the ID token I can't remember if that's a standard claim or not the subject that's that's what it is subject so the way the one of the standard claims that all ID tokens will always have and the userinfo response will always have as well is a SUV or sub claim or stands for subject which is a an identifier for the user sometimes it's like an email address sometimes it's a random string but it's something that uniquely identifies the user does that kind of answer your question correct yeah so I know what you're asking about think about think about open ID Connect as the the common like I think of it as like the glue between an application and the login system how the data got there is kind of irrelevant to open ID connect the data under the under the hood that data could be could be in a sequel database it could be in an excel file it could be in Oracle or whatever but open ID Connect is kind of a common layer that if everybody speaks that then we can at least get somebody logged in yeah that's that's actually a little bit more complicated use case that would be something like account linking where you could link an existing account it sounds like you're talking about an application that already has local user accounts yeah yeah in that case you would you would need to have some way of linking that local account to the identity somewhere else yeah yeah yeah yeah yep there's there's different ways that you can handle that usually it it usually it involves if you have some row in your local database you can you know have a column that that connects to that sub claim that you know is referring to the user on the remote system that's one way to do it sometimes in some situations you don't have any local user table at all you just know that you're trusting completely the the remote system is your you know source of identities that would be more like maybe you'd have a totally greenfield application that you set up from the beginning with open ID connect and you just treat maybe you are running your own authorization server and you treat the identity is coming from that authorization server as your real identities in the application there's there's different ways you can do that more questions I'll get to you next ah I didn't I didn't call it that but I did talk about that before I don't really have a slide that talks about it but so I think what you're referring to is when you have an access token that's not a JSON web token it's just some opaque string right so there's different ways of handling access tokens in the Oh in the OAuth 2.0 spec I'm not talking about open anyconnect but just base off 2.0 the access token is just a string and it is sometimes referred to as a reference token the reason it's referred to as a reference token is because that string doesn't mean anything to me as the client I can't decode it I can't do anything with it all what I can do with it is just send it over to the authorization server and or use it in request to the resource server or I can send it to the authorization server and ask hey is this token still valid it's called a reference token because it is just referencing some State on the authorization server the the token itself is stored in some database on the authorization server where there's like you know is still valid true column or an expiration column or whatever you can contrast that to what's called a stateless token which is a token that isn't stored on the authorization server it is set up with an expiration time and information and and a signature that's all baked into the token like a JSON web token where the server the authorization server actually doesn't have to keep track of the token anymore it doesn't like save it in a database somewhere it just trusts the cryptographic signing that's used on the token to ensure that it wasn't tampered with this that involves how you deal with token validation so let's say that you are dealing with tokens maybe you're running a resource server and the requests coming in to your to your API have tokens attached to them authorization bearer and then some access token you have to make sure that that token is still valid hasn't been tampered with or for or made up or whatever so there's basically two ways of validating a token you can always do the second one which is called introspection token introspection is where you take that whole access token and you send it over to the authorization server and say hey authorization server is this token still good and the authorization server responds with either you know true or false that is a really strong way of token validation because you're trusting the source of the access token which is the authorization server to validate it for you but it of course requires a network request so it could introduce some latency there's a faster way of doing token validation which is what's called local validation if the token is not a reference token but is a stateless token you could validate it the client could validate it themselves by checking the signature on the token this that only applies if the token is a JSON web token as I mentioned before in a auth 2.0 it's not guaranteed that the token would be a JSON web token an open ID Connect it is guaranteed that the ID token is a JSON web token that gets kind of complicated but the the the difference I guess to to boil it down really far the difference between a stateless token and a reference token is that one you have to go talk to the authorization server about the other one you could potentially if it's stateless you could potentially validating yourself does that kind of answer your question yeah yeah so that that is that's a really good thing what he's talking about you're talking about token replication being able to say like a token was issued but then at some point either the user they logged out they got compromised they got fired whatever something happened and we don't want them to be able to make requests anymore if if you're using totally stateless tokens you're just trusting the signature and the expiration time on the token as your validation mechanism then you the best you could do is just hope that the token expires soon that's it because you're just trusting the token based on its expiration time and signature if you are using tokens that are tracked on the authorization server reference tokens then that means that your requests are a little slower because you have to go over to the authorization server every time and check to make sure that they're still valid but that gives you the additional benefit of being able to you know cut off a token before it expires by revoking it that would look something like this you could like post over to a revocation endpoint and say hey this token that is still good right now I want you to stop stop it cut it off this is really common you'll see this on the user side in systems like Facebook and Google where you can say hey my account was compromised and like disconnect all my mobile devices shut all that access down under the hood that's all it's doing it's just revoking a bunch of tokens yeah you had a question oh yeah no I actually have not covered token refresh as you as you can see this topic starts out like nice and clean on the high level and then it gets in this huge rabbit hole that you can go like a million years on in every direction token yeah exactly token refresh is another thing that that a lot of people talk about so the idea here is that we've been talking about going through the Oh auth flow the OAuth dance and getting an access token there's another mode in which you could get an access token and also something called a refresh token now the Refresh token would be used if your access token expires but you want the user to still be able to do stuff you want to get a new access token so you can use that refresh token to get a new access token really fast now this is this part gets a little bit confusing and this like I was confused about this for a long time the the normal way let's say the normal way of getting a new token if your token expires let's say that let's say your authorization server has tokens issues tokens that last for 30 minutes so your access token is good for API calls for 30 minutes at 29 minutes you can still make as many API calls as you want at 31 minutes they're gonna start coming back 401 unauthorized that token expired so the normal way you could get a new access token is you would just send the user's browser through that flow again over to the authorization server request you know response type code get a new authorization code exchange the authorization code for an access token you got a fresh access token new 30 minutes you can keep making as many requests as you want now it you would think that or that might sound like it would take a long time to go through that flow again but if the users already accepted those scopes and they still have a session on the authorization server it takes like 200 milliseconds or like really fast you actually saw it happen when I showed you my demo where I was supposed to it was supposed to ask me to log in to Google but it never did it just came right back with a code like it's immediately that was because I was already I was still logged in and that's exactly what happened so that's how you could get a new access token the normal way now if in certain situations let's say that maybe you don't have the user's browser anymore to be able to do that if that's your situation then you can use what's called a refresh token to do that process in like an automated way so a good example of this would be let's say that I authorize you to you know have access to my account be let's say there was a service I'll say I'm running a service that looks at your email every night like cleans up all the semi drunk mail that you like probably don't want to read but maybe you want to read and it puts it all in like one folder and it's supposed to do that every night at midnight well the initial way that I gave you access to my account was I you know connected to my gmail account I clicked allow give you scope to read access or actually rewrite access to my email and you've got a token your application got a token to do that and that token lasts a week and every night at midnight you've been running that clean up job and I'm really happy as a user cuz I don't see all the spam from the newsletters I forgot I signed up for or whatever now after that token expires after a week now what are you gonna do you can't run that job anymore at night because I'm not the users not around to let you go back through the browser and and potentially click accept again or probably wouldnt have to click accept again but at least you don't have a browser anymore to go through that flow again so what you do then is you request one extra scope at the very beginning a scope usually called offline underscore access if you request that offline access scope during the code exchange you exchange that code like normal you get an access token like normal you also get a refresh token you hold on to that Refresh token and all that refresh token is all the Refresh token is good for is getting a new access token programmatically once the first one expires so typically that access token might last maybe say that lasts for a week the Refresh token lasts for a year when that access token expires I'm like hey I got a refresh token I'll go send up the Refresh token get into access token I don't have to bother the user I don't have to send the user's browser through that through that flow again so I can just keep getting access tokens as long as I want until the Refresh token expires and then once that happens then I really have to like bug the user to reauthorize my application that was a pattern that was used a lot by mobile apps and by like integrations with Google a lot of times authorization servers will just make the Refresh tokens last like 10 years or something I think that was Facebook's choice for their app because they just didn't want a bug about logging in all the time I I don't think that's a great idea to have them last for ten years because that's like a there's security implications to that but that's how the refresh token mechanism works does that kind of make sense some nods but that could be people nodding to sleep so any other questions I've gotten pretty far down the rabbit hole now that's good yeah just a string just a string at least from the clients point of view the client should just is just treated as a string it may be maybe it might be like a JSON web token under the hood but the client shouldn't assume that the expiration is tracked in the authorization server yeah so there's an there's kind of an interesting nuance here that took me a while to understand which is if you're using the normal way the way that I've described where to get a new access token you send the user's browser back over to the authorization server and it bounces back immediately the reason why that is good or that has some advantages is because what it in what it forces you to do is basically check back in with the authorization server make sure the user still has a session over there on the authorization server and assuming they do they get back really fast the refresh token kind of does the same thing it makes you go back up to the authorization server with that refresh token but then with a refresh token it means that there's like another thing that you have to revoke if something goes bad if you if the user gets compromised then you have to make sure you revoke that refresh token otherwise someone who has that refresh token could for that whatever however long it lasts a year 10 years or whatever they could keep getting access tokens for that user and potentially doing bad stuff so it's just one other like security aspect you have to keep keep track of no no I think that's a good practice that's one of the that's one of the kind of knobs that you can adjust so for anyone who wasn't able to hear he was just describing that what you can do you can have really short lived access tokens which is good for security because if your token only lasts you know five minutes or ten minutes or something then if it's compromised at least there's a really short window where someone could do any damage then you could have long-lived Refresh tokens which allow the user to keep getting new access tokens for a long period of time and that kind of gets around the fact that each access token only lasts for a short amount of time that at least the the advantage of doing that kind of short-lived access token long live refresh token is that it makes you having to keep it means you have to keep checking in with the authorization server with the Refresh token to get new access tokens and that gives you a place like a checkpoint where you could if you needed to like revoke something it still does mean that you have two things that you need to like keep track of revoking if you do any type of replication rather than just one so yeah but that's that like long-lived short-lived pairing is a pretty common yeah oh yeah that's good yeah yeah so what you're describing is kind of like a like a sliding refresh token I guess I don't know if that's the real term but that's kind of how I would describe it where you can you can think of a refresh token behaving in one of two ways either you use a refresh token and get a new access token you always get the same Refresh token back and that has like an absolute lifetime or every time you use a refresh token you get a new refresh token back and that lifetime the Refresh token lifetime is allowed to kind of slide along and potentially stay indefinitely alive the the tricky part about that or the the security part that I'd be worried about is that that potentially means that someone could have an unlimited amount of damage that they could do they would like never get cut off if they if they compromised your refresh token then they kind of like have the keys to the kingdom I guess if if you never like notice that they compromised your refresh token so usually the best practice that I see is that refresh tokens have an absolute expiration that eventually gets just expires and you always get the same Refresh token back but I've seen it that way too I'd be interested too I'd be interested to understand in your application we can chat after our if you're using refresh tokens for that kind of automated the automated use case that I was describing before or just to keep like a web session alive okay yeah yeah yeah so like you're you're trying to solve the case where like someone closed the browser but then they're like oh I've heard I just forgot something I went right back and I didn't have to login again I think I think the best way to handle that like keeping a web session alive is more the the flow I described before where you redirect back to the authorization server and let the authorization server keep track of its own session for the user and that is what kind of like keeps letting you have access tokens that's not always I'd be interested to chat with you afterwards that's not always possible and like some web architectures maybe but that's if I was building a new application that's what I would do I've built applications in the past that did it like how you're describing where you use a refresh token to keep the web session alive I think I would now use an author is it a session on the authorization server to keep it alive any other questions I had a great time hanging out with y'all thank you so much for your time you

Channel: OktaDev

Views: 43,438

Rating: 4.9467554 out of 5

Keywords:

Id: 0VWkQMr7r_c

Length: 96min 46sec (5806 seconds)

Published: Fri Apr 06 2018