OAuth 2.0 and OpenID Connect (in plain English)

you alright let's get started welcome everybody my name is Nate and I'm gonna be talking about OAuth and open ID connect today I worked at a company called octa up in San Francisco and I do a lot of web security stuff and work on just making it easier for developers to do authentication and authorization in their applications and so through talking to a lot of developers I've noticed that a lot of people have have heard of these protocols o auth and OpenID connect but a lot of people don't really know what they are or maybe they understand them a little bit but not not really understand them fully so just as a quick poll who here has at least heard of Open ID Connect or oh ah awesome what about would you would you feel like you're an expert on it or you really understand the protocol at like a pretty good level not me not me these are pretty difficult protocols to understand especially for some reasons that we'll go into in a second there there's a lot of confusing information about them online so my goal with this talk is to just cut through kind of the the jargon cut through the technical speak and try to explain how these protocols work just in play try to just make it really easy to understand and we are gonna get into some of the technical stuff today because we have a little bit of extra time but if you have any questions at the end feel free to ask them I'll try to make it as easy to understand as I can so what we're gonna do first is we're going to talk a little kind of start with a little bit of history to come because it's helpful to kind of set the stage and understand where these protocols came from and why they were built the way they are and that'll inform kind of how we understand how they're supposed to be used today all right so if if you're interested in the the slides or the video from this talk it's available and will be available on my Twitter at the end at a 10 bar batini and if you want to follow my whole team we tweet out a lot of good content like this you can follow at octave alright so let's get started before we even talk about OAuth and OpenID connect I want to kind of set the stage and talk about the the most basic type of authentication you can do on the web this is the simplest case I'm calling this like simple login or sometimes it's called forms authentication and this is just a simple example of where you have like email and password or a username and password form on a website the the user enters their information and your back-end website code is going to like go hit a database somewhere look up see if that username and password actually exists if so you know verify that the the password matches hopefully doing like password hashing to make sure we're not like storing the password in plain text looking up that users information and then usually what would happen is the application would drop like a cookie into the web browser to keep track of the user and say hey this user already logged in they're associated with this particular session ID or something and we've logged the user in now this is basically how authentication started out on the web this is like a lot of people including myself cut their teeth on building this type of thing like in PHP or in my case classic ASP some really really bad code that I never want to look at again from like 15 years ago but you can do this on your on your web server if you want the the industry has been moving a little bit away from kind of doing this in a homegrown way and I'll explain why so this doesn't have anything to do with though OAuth yet but I wanted to kind of set the stage for explaining what were what we're gonna be comparing against this is like the most simple use case there's a couple of downsides of doing authentication inside of your app kind of like in a homegrown way like I just described the downside is that when you do it that way you're on the hook for all of the security and maidens that goes around with maintaining an authentication system so it's just your server code hitting a database somewhere and you know making sure the user's password matches then you have to be aware of like when the best practices and the security is to change around password hashing or storing user information securely or you have you know HIPAA coming down the wire or now gdpr it's on the wire you have to be aware of like how these things change and there's quite a bit of maintenance involved in making sure that your ten occasions is still working so at risk of giving away the punchline just a little bit ooofff 2.0 and open then you connect are kind of some industry's best practices that the industry as a whole is moving towards to try to make this problem a little bit easier to solve but I'm getting a little ahead of myself so let's explain what how these protocols work in what they are first and then I'll come back to that so I want to acknowledge that there's a ton of really confusing information about OAuth online if you try to Google what is oweth or how does open ID connect work or how do I use OAuth 2.0 you're probably going to find extremely confusing information when I started learning about this a couple years ago when I got into like the web security space it was really confusing for me too and I still get confused sometimes even today I think the guys who wrote the spec still get confused as well the the thing that you'll find online and why it's so confusing is that for mainly two reasons there's a lot of terminology and jargon that's just like really dense really obscure and like really just like very op 2.0 specific so the problem is that if you are a newbie or you don't really understand how this works yet and you Google to try to figure out how it works what you're probably going to find is a lot of information that that talks to you as if you already understand all these terms already understand all this jargon but if you don't know what those things mean you have no idea what it's talking about and that can be really confusing the other thing that's really difficult when you're trying to learn this is that there's a lot of actually incorrect information online as well so if you google with some of these terms the most likely thing you'll find is probably like one guys Stack Overflow post that explains how to use OAuth a certain way and then the very next result will be like somebody else's blog post that says he's doing it wrong and you should really do it her way and then the third result is like an entirely different blog post that says they're both wrong and you should not do it that way at all because that's the worst thing to do that's obviously really confusing when you're learning this you're like who's right why when we have a spec which otherwise should be hopefully very like very concrete why do we have so many different interpretations of like how to use it that's obviously that doesn't happen with like HTTP there's like one pretty correct way to use HTTP and that's about it but with OAuth unfortunately there's all this kind of wiggle room there's a little bit of fuzziness in the spec so that makes it really hard to I just wanted to kind of acknowledge that if you've ever felt confused or overwhelmed or or intimidated by this stuff you're not alone pretty much everybody has my goal today is to try to make it a little bit less intimidating a little bit less confusing and you can let me know at the end if it makes a little bit more sense so let's go back in time let's take our time machine and go back in time about maybe 10 years back to like 2006-2007 this is a long time ago especially in internet years this is a long time ago because back in say 2006 we didn't even really have smartphones that was like brand new but the iPhone came out in like Oh 7 I think so this is a long time ago back then though just like today applications and websites had a number of different use cases that they might have to deal with in terms of like login authentication authorization I'm just going to use the term identity as kind of like a catch-all term for like authentication authorization login permissions that type of thing so if we look at the kind of common identity use cases from like 10 years ago we have that simple login stuff like I said which you could probably just fulfill with like some form and some cookies or something just login the user in with like a username and password that's pretty simple we also have some apps that need to do single sign-on or SSO and that was typically done with a protocol called sam'l and today it's still very often done with a protocol called sam'l as well the sam'l protocol is very good for this type of single sign-on use case which is basically where you have one account in a system that lets you get login or get access to a number of different systems this is really common in like businesses where you have a single master account or you have like an Active Directory account or an employee account that lets you get into a number of different systems and sam'l is the protocol that kind of makes that work under the hood the the sam'l protocol works it kind of has a reputation of being a little bit hard to work with as a developer because it's pretty it's pretty obscure even more obscure than ooph it's it's very very dense but it works and it was used back then just like it's used today there's a couple of new use cases that were just starting to come onto the scene about ten years ago or so that that were new though so one of them was mobile apps like I said mobile apps smartphones were brand new the idea of apps and App Store was like brand-new and so there's this whole new set of use cases where we want to be able to log into a mobile app but you want to stay logged in you know after you close the app most likely how do you keep a long live session alive on a device do you use like a cookie that doesn't really work well on devices it was a it was a new field it was brand new so we didn't really have a good solution for that right away as well as something called a use case called delegated authorization which probably sounds like the most boring academic thing you could imagine but this is actually what I'm going to focus on here delegated authorization is an interesting use case which is also the genesis or where oh oh oh oh off protocol came out so despite sounding very boring this is exactly what I'm going to focus on so the delegated authorization problem is something that despite sounding very boring something that you probably interact with maybe on a daily basis even maybe today already and you don't even you haven't even realized it so this is essentially who has ever seen the screen that says hey this so-and-so app is trying to access your Facebook account this will allow them to like see your public profile and like your birthday or something but won't let this app post a facebook on your behalf who's ever seen that screen or the same thing with Google or Twitter or whatever that's a really common pattern on the internet now but it wasn't ten years ago it wasn't even around ten years ago that pattern where you get that pop-up or that prompt and you click yes and it allows now you probably have like 15 weird apps that are connected to your Facebook account or something you don't even realize that that pattern is oh oh ah so if you've ever clicked YES on that prompt you've already used OAuth you maybe didn't even know it but let's talk about why that was invented well back like I said ten years ago or so there wasn't a good way of solving that problem there were only bad ways of solving that problem this is a kind of an infamous screenshot from the early days of Yelp where Yelp tried to solve this problem but they did it in a really bad way no no offense to them they didn't have a better way of doing it but at the time Yelp did something that's pretty common at the end of your registration flow you said hey you just thanks for registering for Yelp do you want to you know spread the love send a referral link or an invite link to all your friends so they also sign up for Yelp they were a brand-new startup so they're trying to get you know as many people as possible to use of service the way that they did it was they said hey give us your Gmail email address and also give us your gmail password just in case you weren't clear about what they were asking for that it's kind of small here on the screen but it says in parentheses the password you use to log into your Gmail email just in case you weren't sure which password they wanted to then for you to give them so what they're basically saying is like hey we'll log into your Gmail account for you we'll grab all your contacts we'll send them all an email we will then log out of your Gmail account we'll throw away your password we promise we won't do anything evil with it and then we'll go on our merry way so in case you're wondering this is really really bad you should not do this you shouldn't build something that does this and you shouldn't use something that does this with your Gmail because for many people their Gmail account or their you know yahoo account or whatever their kind of main email account is usually is the keys to the kingdom to a lot of other stuff they have so your bank you know password reset flow probably goes back there your Bitcoin coinbase password reset flow probably goes back there hopefully you have two factors set up on these accounts and stuff but this is just a really really bad idea to just randomly give people your your Gmail password especially because back then Yelp was not the big billion dollar company they are today they were just like a startup it wouldn't have ever heard of so this is really bad like I said I'm not trying to pick on them too much this is just a really good example to illustrate what the problem was back then and how they didn't have a better way of solving it at the time we have a better way of solving it now and today we would use that a lot flow that I just described before you get a pop up and says Yelp wants to get your access to your contacts are you sure you want to allow this yes or no as a kind of an ironic side note there's only one industry that still does this today if you've ever used a tool like mint or betterment or any of those financial dashboard tools that like let you aggregate all your bank accounts and you see them all in one screen when you set up your bank accounts you have to give them your bank login and password to do that and the reason is because banks haven't adopted OAuth yet they're still using this really crappy old way of doing this so you know that your information is really secure when you do online banking that's great so let's talk about how you would solve this problem how banks should solve this problem and how a company like Yelp could solve this problem with OAuth basically the protocol that was invented to solve this problem basically we're gonna talk about it at a really high level and then we're gonna kind of progressively go down and talk about the lower and lower levels of how this works so we start with a user like me or you who says like okay I trust Gmail I maybe kind of trust this this startup called Yelp I trust them enough to let them have access to just my contacts but I don't want them to like be able to delete my email or you know go look at night Google photos on Google Drive or whatever so what we would do today is we would have a button on the application on Yelp or whatever that says connect with Google or authorize with Google or a link or whatever what that what happens when the user clicks on that button or that link is the user is put into what's called it sometimes an OAuth flow it's basically the set of steps that ultimately results in the application being able to access that information or having the authorization to access that information so we're gonna look at this diagram like five times and you're probably gonna get really tired of seeing it but this diagram is going to kind of illustrate at a high level how this works so let's say the user clicks on that connect with Google button or link to Google button what's going to happen is the users browser is redirected over to a Google domain accounts.google.com most likely and at that Google domain they're gonna be prompted to login so probably enter email and password that that's at least a little better though because now at least I'm giving my password to Google and not to Yelp or somebody else so I should feel ok logging into Google I can see that in the address bar it's actually a Google domain that that I'm being presented with assuming that I login successfully then I get a prompt that says hey this application Yelp is trying to access your list of things public profile contacts something like that are you sure you want to allow this yes or no so the user explicitly has to consent to whatever they're granting access to that's important so that you don't get tricked into like agreeing to something and you don't know what you're agreeing to and then assuming the user clicks yes they can always click no in which case we're done nothing else interesting happens but if the user clicks yes then the browser is reacted one time back to the application back to where it started to a special place on the application called a callback or a redirect URI I'll talk about that in a sec and with a little bit of magic that application is then allowed to go talk to some other API say the Google contacts API and say hey normally I wouldn't have access to Nate's contacts but I have this special magic thing that tells me that I'm allowed to have that now that neat click that yes button so there's still a little bit of magic in this diagram but we're going to remove the magic in a sec by talking about all of the different terminology that goes into this so here's a big lung bucket of terminology for you in the kind of waft 2.0 landscape side note by the way there is an oauth 1.0 but we're not talking about that today because for all intents and purposes it isn't used anymore it's just kind of dead deprecated nobody really uses it oo-ahh 2.0 is used very widely on the Internet today so in oweth terminology we have a bunch of terms and jargon that basically just renames things that we already have names for which is kind of confusing but we'll go through them all here so in a lobster quenelle we have something called a resource owner which is just a really fancy way of talking about you or me the user who can click yes who's actually sitting in front of the keyboard who owns the data that the application wants to get to so in this example that will keep using here I have some contacts in my Google account I am the resource owner of that data and I am the person who can click you know yes I allow this application to have access to this data the next term that we need to look at is something called a client this is just a way to refer to the application we've been using Yelp in this example will just keep using Yelp Yelp would be the client in this case the the application that wants to get to this data basically we also have something called an authorization server the authorization server is the system that I can use to say yes I authorized this permission or I authorize this to happen in this case that we've been using this is a accounts.google.com where I can login to my Google account and click yes I consent yes I accept that's actually separate than the resource server which is the API or the system that actually holds the data that the client wants to get to so in this case this is we're gonna call this the Google contacts API this is the system that actually holds my contacts sometimes the authorization server and the resource server are the same thing sometimes they're kind of together melded in the same system but many times they're separate so the whole point of the whole Alois flow going over to the authorization server coming back to the client the point of getting of doing that hold kind of danced back and forth is to get something called an authorization grant and the authorization grant is the thing that that basically proves that the user has clicked yes I consent to this level of permission or I allow you to have permission to this stuff I already mentioned this a little bit before but the when the authorization server redirects back to the client application it kind of needs to know where to redirect back to and that sometimes called a call back sometimes called a redirect URI it's basically just where should I end up at the end of this flow if the user clicks yes where do where do they need to go next and I mentioned how the authorization grant is kind of the point of this whole flow well at an even higher level the the thing that the client really needs is something called an access token an access token is going to be the way the key that they use to get into whatever the data that I granted access to or granted permission to on the resource server so as you'll see in a sec the client will eventually get something called an access token which lets them go do what they need to do so let's go through this whole flow again and add some of these terms in bit by bit so we're going to start on the client with me the resource owner probably sitting on the client website and I click on that connect with Google button what happens is I get redirected over to this authorization server which is accounts.google.com in this case but it could be the Facebook authorization server it could be an authorization server hosted by octa it could be somebody else right at the beginning of this flow as the client is redirecting over to the authorization server it's already passing along some information some kind of configuration information that the authorization server needs so it's saying hey when you're done assuming everything is successful here's where I want you to redirect back to at the end so we have to pass that redirect URI at the very beginning we also have to give it some other information such as what type of authorization grant do we want there's actually a few different types of authorization grants and I'll go into that a little bit later in this case we're gonna use the most common kind of like simple example which is what's called a code grant or the authorization code grant because we're requesting a code this is sometimes called the authorization code flow and at the end as you'll see we'll get a code but I'm getting a little ahead of myself so the authorization server then prompts the user login consent to that permission all that good stuff redirects back to the place specified at the beginning the redirect URI and redirects back with something called an authorization code because that's what we asked for at the beginning now the client actually can't do a whole lot with that authorization code in fact there's only one thing that the client can do at all with the authorization code which is to go back to the authorization server one more time and say hey you just sent me this authorization code what I really want is an access token I can't really do anything with this code but I want an access token can I exchange this code for an access token and the authorization server is going to say sure let me just make sure that code is still valid isn't been like forged or you didn't make it up or something and it assuming that's the case the authorization code is still good the authorization server says ok client here's your access token and then finally the client can do what they actually want us to do in the first place which is go to the resource server maybe contacts google.com and say hey I want to get to Nate's contacts now normally contacts are google.com and say you can't have access to nice contacts who are you but because the client is able to attach this access token to the request then contacts are Google com is gonna say ok normally I wouldn't let you have access to this information however you have this access token that proves that Nate said it's ok for you to access that information here you go now if the client tried to do something else like maybe not retrieve my contacts but like go delete all my contacts hopefully contacts not Google comet say okay you have an access token but it doesn't mean that you can do just anything Nate said you have access to maybe read-only access to the contacts you can't go like delete them or you can't go look at his location history and see where he's been or whatever so this basically this whole flow here this is this is the whole thing the entire rest of this talk we're basically just going to be talking about slight variations or slight details of this flow but this is the whole thing so we're making some progress I talked about how the the access token basically grants access to the client to do a specific thing but how does how does the client specify what thing it wants to do well we need some way of being able to say well the client wants to do like read my contacts but isn't trying to get access to delete my contacts it wouldn't be very useful if it was like a black or white all-or-nothing thing we don't want to have like no permission or every permission we want to have some way of being like very granular have specific permissions that we can turn on or off or request and to add a little bit more terminology to it that is what ooofff calls this idea of scope or scopes the way this works is the authorization server has a list of scopes that it understands so it might be like contacts thought read contacts thought write you know email that read email dot delete basically any type of permissions that make sense in the system and then the client application when they kick off this flow they say okay I don't care about most of those scopes I don't need to read his email or delete his search history or whatever I just want the scope that gives me access just to read his contacts and that's it or if they need to do more stuff they could request multiple scopes depending on whatever level of permissions they need to have with my data and then on the flip side of that that list of scopes that list of permissions that the client is asking for is then used by the authorization server to generate that that screen that consent screen that is presented to the user that says hey Yelp is asking for permission to do XYZ ABC are you sure you want to allow this and the users give an explicit the explicit ability to consent or not consent to that particular level of access or that particular list of scopes in in the case of Facebook they've they changed their authorization server recently to be really explicit about let you know whether or not an app that you're giving access to is allowed to post to your wall because early on it wasn't really clear it was like do you want to let this app connect to your account yes or no and if you click yes you weren't really sure does that just mean they get my info or does that mean they like get to spam my wall so because that was really annoying and people got really upset about that Facebook made that much more explicit and granular so you have to if you're an application connecting to Facebook if you're a client you have to say I do specifically want the scope that lets me post to their wall or not and then in the consent screen it's made really clear to you which is nice so let's look at this diagram one more time not much changed here except at the beginning the initial request over to the authorization server the client specifically enumerates all the scope all the Scopes separated by spaces that they need to have against the user or for the user in this case let's say that this the Yelp application just wants to access my public profile and my contacts I'm simplifying it just a little bit here because Google scopes tend to be like really long URL strings but this this is the general idea so what's going to happen here is because the client requested scope profile and contacts that's what's used to build this consent screen and then after the after the whole flow completes and the client exchanges that authorization code for an access token and then use it that access token to go call some API that access token itself is limited or scoped to exactly what scopes were requested at the beginning so this access token in other words that that comes out of this flow is specifically scoped to profile contacts that's it that means that Yelp the Yelp application couldn't turn around and then go send some other API request to like you know the Google Calendar API or a delete request to my contacts or whatever because it the access token even though it's valid is not scoped to do those particular things alright any questions so far we've gotten through quite a bit of the terminology great question so the question was how why do we have these two things why do we have to get an authorization code and then exchange that for the access token why don't we just use the code or why don't we just get the access token immediately why is there that extra step it's a great question I swear I didn't plant you in the audience because that sets me up perfectly for what I need to talk about next so that's a great question there's a specific reason why we need to do this extra step why we get a code instead of just getting the token right away and it I'm hinting at it here with some of these lines being solid and some of these lines being dashed but we need to talk about what it means to have a back channel and a front channel so this isn't specifically OAuth terminology this is more like network security terminology but we have this idea in networking of having a back channel or what's considered a highly secure communication channel and a front channel which is a secure but slightly less secure channel I'll explain what I mean so when let's talk about a highly secure channel well if I have my server code running on my server which only I have access to and I make an API request or some some some HTTP request from my server to another server like Google's API for example and that's going over you know HTTP its SSL encrypted no one can intercept that communication it's highly secure that would be considered what you'd call it back channel going from mice my back-end server to some other API or some other some other system a front channel their hand is something like your browser where your browser is secure but there's some because of how browsers are built there's some loopholes or there's some some places where stuff could leak from the browser what I mean by that is let's imagine that if I'm building a website or I'm building a web application I and I want to keep like a secret password or a secret key or something in my web application if I put it in the HTML or JavaScript of my web app technically somebody could just right click view source look through my raw code see it there right if they really want it to go digging or they could open up like the network console or the chrome developer tools and and see what my JavaScript is doing change potentially what's happening on my page so because of things like that or simply someone could be looking over my shoulder and see something that's on the page because of that browsers are considered to be a front channel in other words we can trust the browser but we only like trust it as far as we can throw it not not complete trust we have complete trust in the code that's running on our own server but not complete trust in the browser so as you'll see here we're gonna go through this flow one more time as you'll see here the way this flow is designed including the reason why we have to get an authorization code and then exchange of for a token is designed to take advantage of the best things about the front channel and the best things about the back channel to make sure it's highly secure I'll explain what I mean so let's say that we have a the client which is going over to the authorization server we've gone through this before all of these things are happening on the front channel what I mean by that is all of these are just full page redirects in the browser we have like on the outgoing request here we have the redirect over to the authorization server the stuff that we're passing along to the authorization server the redirect URI what response type we want all the Scopes we want those are all being passed through the browser this is usually just in like the query query parameters query parameters of the of the request so technically if someone was like looking over your shoulder if you're looking at the address bar in your browser you can see this stuff it's not like secret but that turns out that's okay because if somebody sees the Scopes that we're asking for yeah who cares if somebody sees what redirect URI we're going back to at the end who cares because we're gonna go there anyway it's not like that's a secret if you notice coming back from the authorization server back to the client that is also happening on the front channel I've made all the front channel requests to solid lines here that means that the authorization code is also transmitted through the browser through the front channel that means that that's usually also in the query parameters of the request so if you really look if you squint as requests are happening in your browser you can see the code in the query parameters of the address bar so that means the authorization code comes back to the redirect URI to the call back over the browser the next step though happens on a back channel so the reason that the reason we do it that way is because let's say that somebody was intercepting your browser requests or maybe they had a you accidentally installed a malicious toolbar like or something like that in your browser and it was watching your network requests well someone who had had the who could like log work requests would be able to see the code as it came across the browser because it's just gonna be like slash callback question mark code equals something technically they could maybe steal the code grab it themselves and then try to beat you to the exchange and try to get your access token before you could write but it turns out they can't do that because the the exchange happens only on the back channel it doesn't happen on the front channel so that token exchange happens when the application the client grabs that code then makes a back-channel request from the back-end server code to back to the authorization server but that does not happen through the through the browser and again that is for security so we're posting it's an HTTP POST we're posting that authorization code up to the authorization server along with some other information like a secret key that only the server knows so that means that even if someone stole the authorization code they wouldn't be able to make that exchange request and and try to grab your access token before like before you could because they don't have that secret key and the reason this is on the back-channel is because we don't ever want that secret key to be in the browser because if it if it was transmitted in the browser we don't know if someone could have stolen it so we do that only on the back channel on a system we can trust basically our own server code and the communication with the resource server using the access is usually also don't done only on the back channel because once the application has an access token the access token is typically typically considered to be like sensitive information I if I transmit the access token to the browser someone could technically steal it and then they'd be able to do whatever they wanted with that access token whatever it's scoped for as much as they wanted so that part is also done in the back-channel so I said at the beginning that this flow is designed to kind of take advantage of the best the best things about the front channel and the best things about the back channel what I mean by that is the front channel here is used to interact with the user so the browser is used to interact with the user present them the login screen present them the consent screen all that good stuff that's what a browser is really good at but because we can't completely trust the browser with like secret keys and stuff like that we let the the the last step of the flow that exchange happen on the back channel where it's a system that we trust yes yes exactly so the question was does that mean that that we had to do something initially to set up with Google to get that that secret and that key absolutely so let's take a look now we've done we've looked at this this diagram quite a bit this is helpful to like understand how it works at a high level let's look at a little bit more like raw how this actually works and I'll definitely answer that question as well so if you were to look at the the link or the button that you click on that says like connect with Google or link to your Google account this is actually where that would be going to this is what your browser gets redirected to it's an address on the authorization server that you then pass a number of parameters to or some configuration to so I talked about some of these already the redirect URI what scopes you want what responses something that you set up one time with the authorization server with Google in this case and then we usually pass along something called a state which is just like a text value that gets sent over and then comes back at the end but let me show you I'm going to switch switch gears here for one second I'm going to show you what it looks like to set up one of these there we go so let's say that I wanted to I'm building the next Yelp and I want to make this work I want to be able to have people authorize their Google account and so I can get access to their contacts what I would have to do is I would have to do a time set up step where I go into Google I go to the authorization server and I say I'm gonna create a client and by creating a client I get two things I get something called a client ID which is actually this value that you can see right here it's kind of a long a long string the whole thing and I also get something called a client secret which isn't shown here because it's a really like sensitive piece of data so with that client ID and client secret that's that was what identifies me to the authorization server so the client ID is passed along with the initial request which is on the front channel because the client ID is not sensitive it just identifies the Yelp application the client secret on the other hand is basically like my secret key this is what I use in the back-channel request during the token exchange step and I'll show you how that works in just a sec what I want to do is I want to show you how this kind of how this looks in the real world so let's say that I wanted to test this out I because it can be pretty difficult to to kind of get this working the first time because you have to make sure you have all the parameters set correctly and stuff I am on I'm not on Wi-Fi apparently I created a tool called OAuth debugger comm which just makes it a little bit easier to test these things and see what's happening one sec which isn't working right now could be because I'm on the wrong Wi-Fi let me just double check this or it's because I'm giving a demo and the demo gods said not today okay so it's my Wi-Fi oh cool you try the Ethernet instead secure secured perfect thank you it was the wife I thank you very much so where was I so I built a tool called OAuth debugger try it out at OS debugger calm it basically just makes it easy to set up the request and then see if it worked and then once you know it works then you can like take the debugger out of the loop and put your relocation in there and it everything should work so I'm just gonna use this to demo what it looks like to make a request against Google and see what happens so this basically just then from Google from the the console I'm gonna request the scope profile which just gives me basic test users profile information so far which is response type code meaning I'll get an authorization code back from the authorization server and let's just give this a try see what happens it's gonna ask me to login notice my URL here is accounts.google.com so we're over on the authorization server I'm gonna login since I logged in recently it's probably not gonna ask me to do my password and okay so we came back this because the redirect URI that I specified here temporarily was my debugging tool it came back to my debugger and you can see actually here if you squint you can see the authorization code here in the in the address bar or you can just see it right here so this is the authorization code we got back from Google like I said this isn't very useful except to do the next step which is to exchange it for an access token now you can't do that through my tool here because that would require sharing your client secret with my tool and you shouldn't do that with anybody even if you trust me but I'll show you what that next step looks like get my slides back up all right okay so this is basically what we just did a suit if the user if the user clicked no I do not consent to this or maybe you didn't set up the parameters correctly something went wrong you'll get the authorization server will redirect back to you an error but we did it all correctly and I clicked yes so we got back a code which is what we asked for at the beginning now the next step like I said is exchanging that that code for an access token so what that would look like that's the wrong way well that would look like is a HTTP POST to the authorization server on a different route called the token endpoint or the token route and basically we just send along a request that has the code that we just got our client ID this time to include the client secret which is that kind of really sensitive bit of data the secret key that we should only keep on the server and then we just say hey authorization server I just got this code but I really want to token please give it to me and assuming that token the code wasn't like made-up or forged or something that's exactly where you would get back you would get back a response that says here's your access token it's good for this many seconds maybe like five minutes or an hour or five hours or whatever makes sense and then the client finally has what they what it wants what it needs which is an author's access token that can be used to make a request so that request might look something like this maybe go call some other API or some other system we attach the HTTP authorization header to the request and we say bearer and then the access token itself because because of that sometimes access tokens are called bearer tokens and all that's all that's really doing is just saying okay the clients making a request through the to some system to some API including that token in the request and then it's up to that downstream API to say okay I need to make sure this token is valid they didn't just invent this token they didn't make it up it hasn't expired and it actually does have the scope to do what they're trying to do so if this request was like you know delete contacts hopefully that API would reject it even though the access token was valid but assuming all the checks all the validation works out then basically the request is approved is is succeeds and then the client holds on to that access token and they need to make another request they just attach it to the next request and keep going like that so I mentioned that there are a couple of different flows or a couple of different ooofff grant types we've just been talking about this authorization code flow or this authorization code grant type where you get a code back that's why it's called that and that uses both the front channel and the back channel together to kind of make a really highly secure method of exchanging this information there are some other ways to do it though there's something called the implicit flow if for some reason you don't have a back channel you only have a front channel then you can do what you mentioned earlier which is skip that exchange step just give me the token right back from the authorization server don't give me a code just give me the token instead and that's use sometimes when you have situations like I said where you don't have a French you don't have a back channel you only have a front channel and that sometimes happens when say you have a pure JavaScript app like a pure reactor pure angular app that has no back-end it maybe has some back-end API that it's calling but it doesn't have a back-end server that's actually like rendering the page and has the ability to run some back-end code so in that case if you have like a static single page app written in JavaScript you don't have a back channel so the only thing you can do is do this all in the front channel I'll show you an example of that in just one sec but I wanted to cover the other two flows that are sometimes used there's one called the resource owner password flow or the resource owner password credentials flow it's quite a mouthful and there's something called the client credentials flow those two flows are back back-channel only so they don't involve the user's browser at all this is basically just your code your back-end server code posting a message to the authorization server and saying hey I've got these credentials just give me an access token right away they're not they're not as commonly used as the first to the client credentials flow is sometimes used when you're doing like a machine to machine or service communication and the resource owner password flow is sometimes used to like kind of like make older older applications work correctly but it's not that like recommended approach for new applications I can talk about about that more if you want a little bit later but I want to show you an example of the implicit flow which is again front channel only if we don't have access to a back channel this is what we have to do ideally if we have a back channel we should just use the back channel and use the authorization code flow which is what you would do in most web apps and mobile apps but if you're in like a single page app you don't have access to that what you can do is you'll notice all these are solid lines go over to the authorization server instead of response type code we're saying response type token which means give me that access token immediately don't give me a code that I have to exchange which means that coming back from the authorization server we just get the access token right away we don't we don't have to do that exchange step and then we can go talk to a resource server with that access token all entirely on the front Channel so like I mentioned before this is considered to be a little bit less secure because you don't have that additional assurance that the exchange step happened on a back channel you don't have an assurance that the token is not exposed to the browser because obviously the token is directly exposed to the browser and that's okay if you're doing if you have a single page app this is sometimes the only way to do it and it can make sense in some situations you just have to be aware of the security trade-offs you're making and you have to make sure that there's no way for the token to be stolen from your app just good good security in general all right I think we have a question here oh it looks like it was already answered if if you do have a question on the on the webcast you can just enter it in and I'll get back to it all right so let's revisit our time machine but we're gonna fast forward a couple of years so we were in like 2006 or so we looked at how the Olaf protocol was invented to solve this delegated authorization problem where I just need to like basically exchanging permissions between systems across the Internet well if we fast forward a couple years the the OAuth 2.0 protocol got adopted like like gangbusters it was like very popular for solving this problem which is awesome because the ton of people adopted it became like a really well used standard on the Internet the problem was it became a like two to two used standard on the Internet it kind of became a victim of its own success in a way it wasn't people started to use it not just for the delegated authorization problem but also for all these other use cases like mobile apps and sim just simple web login and single sign-on and all this other stuff does anybody remember when the facebook login button first came out it was like 2009 maybe but before before the facebook login button the idea that you could log into a site with like just your facebook or google existing like social credentials wasn't a thing it was kind of a new idea I think it was like 2009 2010 well if you look under the hood the way that Facebook create kind of built that blue login with Facebook button and/or Google built the login with Google button that's like kind of ubiquitous across the web now is they just used OAuth that just use OAuth under the hood because they said hey ooofff is really popular it solves these news cases really well and why don't we just use it for this authentication use case as well so we end up in this situation where Olaf is being used for authorization which it was originally built for and also being used for all these authentication use cases as well and unfortunately Oh F was never designed to be used for authentication and I know that sounds kind of like maybe I'm splitting hairs it's a bit of it like an academic difference but there's actually a big difference and there's reasons why you shouldn't use OAuth for authentication this happens to be why it's tends to be so confusing to read about OAuth online because if you just hit a random site talking about OAuth half the time they're talking about using OAuth for authorization for permissions which is originally what it was for and half the time they're talking about using it for authentication which in my opinion is a bit of a hack it's not what the protocol is for so let me let me explain why using OAuth for authentication is bad because in ooofff there's no standard way of getting the users information so if you think about let's say that I'm a website and you just logged in I probably want to know at least a little bit of information about you like maybe what's your email address what's your name who just logged in that would be useful to have well o auth was designed for permissions scopes it cares about like is your access token scoped to a particular thing it doesn't really care who you are so there is no way in the OAuth protocol to get the users information so that means that when Facebook built the facebook login button and Google built the Google login button and Twitter and Microsoft and LinkedIn everybody build these social login buttons and they used OAuth under the hood for it they all had to add their own like kind of custom hacks on top of OAuth to make some way of being able to get the users info and some other some other things that is just kind of missing which is again why it's sometimes so confusing to read about this online all of these implementations ended up being just a little bit different they're not really quite interoperable this is bad when we have a standard we hopefully want it to be like super interoperable and and used the same way everywhere so because of this problem because of the kind of faux off being overused for this authentication use case some really smart people kind of went back to the drawing board and they said okay Oh auth works really well it solves this delegated authorization problem really well now a bunch of people are using it for authentication not great they're all doing their own weird hacks on top of it to make it work thanks Google and Facebook why don't we try to add just a little bit whatever Oh auth is missing for that authentication use case why don't we just add a little extension on top of OAuth to make it work for that authentication use case as well because it's pretty close it's just not quite all the way there so out of that effort came this protocol called Open ID Connect and it's actually not even fair to call open ID connect a separate protocol it's really just a five 10% layer on top of OAuth 2.0 that says hey if you're using OAuth for these authentication use cases just do this other extra stuff and that's it so open ID Connect isn't really new it's just an extension to OAuth 2.0 specifically what Open ID Connect adds to October know to solve these problems or kind of close the gap for this authentication use case is something called an ID token and that the ID token is exactly what it sounds like it just has some of the users information it represents the ID or the information about the user and if if for some reason the ID token you get back from the authorization server doesn't have all of the information you want you can also request more user information from something called the user info endpoint which all open ID Connect which all open ID connect authorization servers implement so basically what this means is that if I'm using an author if I'm talking to an authorization server that understands open Eddy connect not only do I get to act ask for an access token but I can also ask for an ID token and that's literally basically the only difference between Roth and open ID Connect or the only thing open ID Connect ads and that's some other really nice to have stuff like the the way the spec is implemented is a little bit more standardized and and that's kind of nice stuff to make it easier to use but let's take a look at what it might look to do an open ID Connect flow this is going to look really really familiar because it's without trying to drive the point home too many times it's exactly the same thing the only difference if you squint and look really closely at the very beginning of the flow notice how we're still asking for the profile scope but now we're also asking for this other scope called open ID and that is the only like on the technical level that's the only thing that that means that this is an open ID connect to request rather than an OAuth request it is in if you want to be really technical about it it is both an open ID Connect request and an OAuth request we're just using OAuth to do open ID connect so what asking for that open ID scope means is that when we go over to the authorization server all the normal stuff happens we get asked to allow you know access to your public profile or whatever we get back to the callback with an authorization code we exact code for an access token but we also get back an ID token so we get back both and the ID token can be like immediately consumed by the application to understand or decoded by the application to understand who the user is that just logged in so we've kind of closed the gap for doing authentication not just authorization and then the access token that we get back as the client application can then be used if we need more information about the user we can go then call the user info endpoint to get even more info about the user using that access token so I want to give you a quick demo of this I have an authorization server that is open ID Connect compatible running running via octa up in the cloud so I'm gonna use my the other version of the tool I built called Open ID connected bugger to go ahead and try a request against that if you notice the only the only thing that endeth like I said the only thing that identifies this as an OpenID connect request is this open ID scope that's it so I'm gonna construct this request I'm actually gonna instead of asking for a code like I've been doing so far I'm gonna ask for an ID token so this is actually the implicit flow in the sense that we are not going to get the code we're gonna get the token immediately back from the authorization and I want to do that just so you can see what that ID token looks like so when I redirect over to this authorization server that I built using octa I'm gonna get asked to login ask a security question and all right so we get an ID token back because that's what we asked for at the beginning and the ID token is this long string of gibberish it's actually very specific gibberish but it looks like gibberish the ID token is something called a JSON web token or a JWT sometimes pronounced as a job and that's just a standard way of encoding a bunch of information in a in a way that's easy to transmit over the Internet if I actually copy this ID token just hit on here and then go to a tool that can decode it like JSON web token dot IO just paste that in here and you can actually see what what information is inside of this ID token so it's a has a bunch of different properties in here basically just a bunch of information about me the user so like my user ID or my email address things like that let me switch back to my slides here okay so the the ID token that you just saw kind of looks like this I highlighted some different segments or different chunks of that ID token but if you decode it if you put it through the decoder that I just showed you you get something that looks like this there's a header portion there's a payload portion which is sometimes called claims and you get a there's also a signature portion as well the the claims is what can be decoded by your application stand who just logged in user information when the token expires when they logged in all that good stuff kind of just basic information about the user and then the cygnus also really important because the signature can be used to verify that the ID token hasn't been modified or compromised or or rather changed in any way in flight so the client application can actually take that signature do some crypto math on it and say okay I know that this ID token has been stamped by this authorization server it's still authentic it hasn't been modified someone didn't Forge it Nate didn't go in and try to edit and say that he was somebody else or whatever so that's a really cool feature the JSON web token or JWT standard header payloads claim and signature and so like I said the the ID token because of that signature can be kind of independently verified by the application without even necessarily having to go back and talk to the authorization server also like I mentioned before I could use the access token I get back to go call that user info endpoint if if the information in the ID token wasn't quite everything I wanted to know about the user I can just go to the call the user info endpoint say hey I want information about this user here's the access token that proves that I'm allowed to have this users info and I get even more info about the user sometimes this is like additional stuff like their profile pictures things like that alright so let's revisit our time machine one more time now we're all the way fast forwarded up to today we have Roth 2.0 still being used for those delegated permissions delegated authorization use cases that's correct and now we're also using the correct tool for authenticating use cases to mobile apps for single sign-on or for some like you know just simple login cases we can use open Eddie can act instead of misusing olaf 2.0 for that and just to be a little bit even more specific we would use what we're dealing with permissions and authorization we would use open nd Connect whenever we're dealing with authentication sometimes some people get confused and think that because open ID Connect is like newer then that it replaces OAuth 2.0 or it's better than or whatever but it's not it's not like that at all the there are different tools for different jobs the only thing that Open ID Connect replaces is misusing OAuth for authentication we should definitely not do that anymore but for still doing like permissions and delegated authorization a wasyou porno is the right tool for the job all right so let's take a look at a couple of like practical examples we're almost out of time here I want to show a couple of practical examples of like what oo-aah flows or OpenID connect flows should be used for particular use cases because this tends to come up a lot there's some complexity in the spec about like what flow is used in what what situation and stuff like that but I'm just going to really briefly go through some of these so let's let's imagine that we have a really like a basic web application we just want users to be able to log in this is kind of revisiting that simple logging case that I showed right at the beginning at the very beginning we talked about a simple website that just had like a form with an email and password field and it was just hitting the database or something they look up the users info if we if we reimplemented that with open ID connect what we would do is use the authorization code flow to go over to an authorization server may be run by Google may be run by octa may be run one that you made yourself or whatever but use the authorization server to handle the login stuff and all the application needs to worry about is it knows it's going to get an access token and an ID token back from the authorization server and then just like at the very beginning example it's probably going to just drop like a session token or a session of session cookie rather into the into the browser to keep track of the user and then on the back end it's just gonna hold on to the users access token and ID token while they're logged in the benefit that this has over the kind of very simple forms authentication I showed at the very beginning is that now the authentication system and the rest of the app are kind of a little abstracted they have a little bit of separation there what makes that nice is that then the app and the authentication system can kind of evolve separately if they need to we can do maintenance on the authentication system and updated if stuff needs to change security holes need to be closed all that good stuff open ID connect is just kind of the glue that keeps them tied together in a standard protocol way which is really nice this looks almost identical for native mobile apps so if you have a native app on iOS or Android nobody really uses Windows Phone anymore but technically that to you would do the same exact thing you'd use the Open ID Connect often authorization code flow plus one extra more little extension called pkc e proof code for key exchange sometimes called pixie to just do the same thing get a access token get an ID token save those on the device usually store them behind the you know keychain or on behind touch ID or whatever use the ID token to understand who the user is use an access token to authorize API calls all that good stuff the what's really really nice about mobile is that all of the stuff involving going to talk to the authorization server making sure you use the right flow making sure you do pixie making sure that you do this correctly on each different like there's some some differences between different mobile operating systems like on Android you're supposed to use a specific tab browser control or maybe that's changed now something like that on iOS you have to use the Safari View controller all that stuff is all abstracted away in this library that Google and some other folks worked on called app off so you can basically just use app off and it does all this for you all good the other example I talked about was a single page app with an API back-end this is the situation where you don't have the back channel so you have to use the implicit flow otherwise it's identical you're getting tokens back from the authorization server and you're storing those locally in your app somehow taking some care to make sure that you don't - make sure that those tokens can't be leaked in any way so you need to make sure you're not don't have any XSS in your JavaScript and stuff but that's a little bit outside of the scope of this talk there's also some other cool stuff you can do this is also outside of the scope of this talk but you can do like you can use a authorization server like octa to provide a bridge to older protocols like sam'l or other things that you don't really want to do within your app so your app only has to focus on open ID connect and then you let the authorization server handle all the work of dealing with a protocol like sam'l which is kind of cool but that's all I have for today if you have any questions I'm happy to answer them otherwise you're free to take off I got a couple more resources for you if you want to dig even further into how these protocols work especially how ooofff works hit up Oh Ofcom we have a free ebook that we've published there that goes into like a ton of detail about how it works even more than I got into today and talks about stuff like token like expert and revocation and validation and all that stuff I didn't really have time to go into and if you just want to play around with it if you want to get spin up your own authorization server in the cloud totally free you can go to developer dr. com register for an account create as many authorization services you want play around with them for totally free super easy super cool so thank you so much for your time I'll leave it open for a couple more questions but otherwise have a great day [Applause]

Channel: OktaDev

Views: 956,993

Rating: 4.9559174 out of 5

Keywords:

Id: 996OiexHze0

Length: 62min 17sec (3737 seconds)

Published: Mon Feb 05 2018