OAuth and OpenID Connect in Plain English • Nate Barbettini • GOTO 2020

[Music] hello welcome to oauth and openid connect in plain english i'm nate barbatini i'm the cto and co-founder at cobbler here in san francisco i used to work for octa i worked on their authentication and authorization and user management apis and that's how i came to know and love the oauth and open id connect protocols what we're going to do today is just a very short high level intro to how these protocols work and kind of why they work the way they do there's not enough time to go really deep but my goal is to give you the kind of 10 000 foot view and resources and information if you want to dive deeper at the end of the talk i'll give a link to the longer version of this talk which is an hour or hour and a half and goes a lot deeper into some of the nitty gritty of how the protocols work but you should come away today with at least a high-level understanding of of how they work so let's jump in just to get it out of the way it's worth saying that these are pretty confusing protocols even the folks who work on them uh find them confusing sometimes so if you ever have the misfortune of googling how does oauth work or googling like something about openid connects you may find that there's a lot of difficult terminology a lot of jargon that's pretty confusing at first sometimes you'll find just wrong information wrong advice so if you feel that way if you feel confused by these protocols you're not alone believe me it's it's pretty confusing for everybody including myself so what i found to be helpful was going back and understanding why these protocols exist in the first place that ended up being really helpful to understand why they work the way they do and some of the quirks as well quirks of why they work in certain ways maybe why they are misused in certain ways as well so that's where i want to start today i want to understand the why of why these protocols exist to do that we have to go back in time before oauth existed maybe 10 or 15 years ago actually there's a problem called the delegated authorization problem that's a very academic way of saying how do i let my my website that's over here talk to this other website that's over here and they can share information share some of my information but i don't want to give my password out everywhere now just to set the record straight as well when i say sharing information here in the in the scope of this talk i'm not talking about advertisers sharing information about you like in a way to sell your data or something i'm talking about totally legit sharing of your data such as the examples that we'll see here of like i want to share some of my photos to my photo printing service so they can print them out at costco or i want to share my contacts to some service that's going to go see where my friends are whatever the case may be but i'm talking about like legitimate uses of my data so one of the classic examples of how to do this poorly was back in the day when yelp was first getting started they had as part of their sign up process uh a step where they asked for your email address and your email password in order to go log into your email for you grab all your contacts and send them all like a personalized invite to to come check out yelp now sending an invite to all your friends is something that's like pretty common maybe you'd want to do that but the way they were doing that was pretty bad i'm not just trying to pick on yelp here facebook also did it actually facebook did it up until fairly recently but just to be clear you should not do this you shouldn't be asking for someone's real gmail password in your application so you can sign in as them and then access their email or contacts or whatever but at the time yelp was building their application originally there wasn't a better way to do this there wasn't a standardized way for some application some third party like yelp or whoever it is to go talk to google and say hey i don't i don't care about seeing nate's email and his maybe photos or calendar or whatever i just want to see his contacts and i i don't need to delete them i just want to read them i just want read-only access to his contacts for example there wasn't a way to do that so they kind of hacked around it by asking for your password not a good plan you should not build it like that unfortunately they don't do that anymore the reason they don't do that anymore is because there's a much better way of solving this problem now to solve this problem of asking for permission to see like a little bit of my data or a specific piece of my data the protocol which is now known as oauth 2.0 was invented that was the problem it was invented to solve and we're talking about authorization here we're not talking about authentication quite yet so let's imagine what it would look like to solve that problem today with oauth 2.0 instead of asking for the user to give instead of me as the application here asking for your password your email password instead i'll ask you to click on a button that says authorize with google or connect my google account maybe and what happens when the user clicks on that button is that their browser gets redirected over to accounts.google.com now they may be asked to log in there but at least in that case they're giving their password to google not to yelp or whoever some you know third party then they may or may not be asked to log in depending on whether they're already logged in but the important step is that they'll be asked for this explicit step of giving consent or confirmation that this is actually what the user wants to do now you've probably seen this screen before you've maybe seen it on facebook or on google you've probably seen it a bunch do you want to allow you know x application yelp or whoever to access your blank something some list of things that they're trying to access if you've seen that screen before then you've been in an oauth flow and you may not even have realized it but that's what oauth looks like so asking for explicit consent or explicit permission is a really important step in this oauth process if the user clicks no then we can just go home there's nothing else to talk about but if the user clicks yes then the browser gets redirected back over to the original application yelp in our case and then some magic stuff happens behind the scenes which we'll talk about in a second and yelp then or that that application gets a special access token or a special string that allows them to go talk to whatever they were trying to talk to originally get my contacts for example and now they actually have permission to do that normally they wouldn't be able to but because they have this special token they are able to now if you can understand this what we're seeing here this whole four-step or so process you can understand all of oauth 2.0 this is actually the whole thing there's a lot of terminology and jargon and kind of nooks and crannies of what we're looking at that you can get into and go pretty deep on but if you just zoom out to the high level this is how it works what we're going to do is we're going to look at the same exact flow the same thing again but we'll look at this plus some of the additional jargon and terminology which is like confusing at first but once you see it together it makes a little bit more sense so let's go back to the beginning we'll say we're on yelp.com for example and the user which oauth calls the resource owner wants to allow yelp to read their contacts in a read-only way the client is the yelp application or the third-party application that's oauth just calls that the client so the resource owner the user that's behind the keyboard you or me clicks on a button or a link that that starts the process starts that flow to go connect to google or whoever the whoever the third party is that that owns that information that the client wants that initial step the first step is a redirect over to what's called the authorization server which is the the system that can ask for the user's consent in this case because we're connecting to google it's google's authorization server in that redirect over to the authorization server there's a bunch of parameters that need to be filled in by the client a really important one is where the where this whole flow should end up at the end something called the redirect uri and that will be back on the client there's also a type we have to set up what's called a response type in this case it's response type code which is a specific type of oauth flow called the code flow there are some other flows but we won't look at those today just because we don't have time and then the other thing that's really important here is what's called scope scope is a space delimited list of just names or strings and those are specifically identify what the client is asking for permission to do or to have so in this case it might be like profile space contacts but those names are just what made up by the authorization server they're specific to this google in this case the the google authorization server so if you were building a client if you were coding yelp you'd have to go look up uh the documentation for google's authorization server and understand what what scopes are available like what can i ask for permission to do if you look at the documentation for facebook's authorization server there's a bunch of other things that google doesn't have that facebook allows you to do like ask for permission to post on the wall or something like that poke people i don't know um but the client explicitly lays out this the specific scopes that it's asking for and then the authorization server uses that to drive that consent screen that asks the user it's asking about those scopes it just kind of shows it in a real human readable or reader friendly way you want to allow application name client name to access your whatever those scopes are that it's asking for and different authorization servers will render this differently the facebook authorization server will will explicitly call out whether or not the application is asking for permission to post on your wall or not because that was a big deal a couple of years ago but this is all up to the authorization server it prompts the user for consent it lets the user know what is being asked for what permissions are being granted if they click yes and when they do click yes the redirect happens back to the client specifically to the place where the client had said here's my redirect uri here's where i want you to come back to at the end assuming everything is successful on that redirect back to the client the authorization server sends along a authorization grant basically this thing that represents the fact that the user clicked yes in this case the thing the grant is called a code because we asked for a code the client asks for the code at the beginning of the flow and this code is good but it's not actually super useful what the code is is just a one-time proof that the user clicked yes but ideally the client application wants more than a one-time use token it wants to be able to go talk to the contacts api for example multiple times so the code isn't really useful except to get a longer lived what's called access token what the client has to do is take one more step in order to get the access token it really wants from the code that it got from the authorization server and this additional step is just an additional security measure because technically that code could have been intercepted these are just browser redirects so it could have been intercepted or stolen if there's like some malicious script running on the page or you have a weird toolbar installed in your chrome extensions or something the code could be stolen so we want to make the client do one more step to let the authorization server verify that code so there's an exchange step where the client says okay i got this code what i really want is an access token so i'll send that back up to the authorization server and say hey i have this code can you give me an access token for it the authorization server says let me check make sure that it hasn't been already used or it hasn't expired or any everything else then assuming that all checks out says great here's your access token and the client can then go talk to whatever api it was intending to talk to in the first place and say hey contacts google contacts api uh normally if you if i asked for nate's contacts you would tell me to get lost but because i have this access token it's okay and the google contacts api will see that access token coming in say well let me check first check to make sure the access token is valid hasn't expired isn't you know forged or tampered with in any way and assuming that all checks out says you're right you do have permission to see nate's contacts because he said you do here you go so this is the whole flow with some more of that jargon in there there's more to dig into i'll like i said i'll give some links to the longer version of this talk at the end but if we move on and kind of take a look at what happened in the industry after the introduction of this protocol oauth 2.0 became pretty widely used and adopted for solving this authorization problem google adopted it facebook adopted it and that drove a bunch of people it became a pretty widely adopted standard which is awesome because standards are super useful if everybody's using them then ultimately it ended up kind of becoming a victim of its own success in a way because what happened after that is people started using oauth 2.0 for authentication as well and it wasn't designed for that originally what it was designed for was authorization not authentication now that could kind of sound like a academic difference i guess but there are specific things that oauth does not have in it that are useful for authentication but what happened was if you remember when social login kind of burst onto the scene facebook added the sign in with facebook button and then google did and microsoft it and a bunch of people did um if you look under the hood all of those sign in with x buttons were all implemented with oauth 2.0 it was kind of good because it was a really widely adopted standard so it was fairly you know easy for people to do that i guess but it also was not great because since oauth 2.0 was not originally built for authentication it's missing stuff like uh it doesn't have a standard way of getting the information about who just logged in the a standard way of getting like the user's profile info and because it didn't have that when facebook built the sign in with facebook button with oauth they added their own kind of hack on top of it to make that part work and then google added a different slightly different version of that hack to their to their button microsoft did it a little bit differently and so on so now you have a standard that's being used and kind of extended in these proprietary uh implementation specific ways and it's not as good as a not as good as a standard anymore because it's being used in non-standard ways by everyone so that's a little bit frustrating it certainly made the landscape a lot more confusing and also helps explain why uh some of the information you read about oauth is so confusing as well because when you look closely at what blog posts you read or information you read about oauth half the time it's talking about the original use case of authorization you know asking for permission and the other half of the time is talking about authentication uh logging a user in signing user in or single sign-on across websites or something um which again is not what it was originally designed for so to help kind of untie that knot or solve that confusion some folks went and said look oauth 2.0 is obviously very successful it's very popular it works really well for what it was designed for but it's got some gaps it doesn't quite solve this authentication piece but it's clear people want something that does solve that authentication piece because they're like hacking up oauth to do it so in order to kind of standardize all those hacks that people were doing on top of oauth that is where the the impetus and the effort and the ultimate result of building a protocol called open id connect came from so open id connect is nothing more than a fairly thin layer or set of extensions on top of oauth it doesn't deprecate oauth it doesn't really replace anything it just adds some additional endpoints and additional behaviors on top of oauth 2.0 using the existing mechanisms that are already in place so if you understand how a oauth flow works you already already know basically everything about an openid connect flow except for the like 10 or 20 additional that you have to understand about the specific way that openid connect works for authentication so that kind of brings us to the current practice where oauth 2.0 is still widely in use for the thing it was designed for asking for permission you know asking for authorization between different systems and now openid connect is being pretty widely adopted for the authentication piece for if you want to actually sign the user in or you want to do like single sign-on across multiple websites that's where openid connect really shines and you're seeing that google rewrote their sign in with google um functionality using openid connect now as it should be instead of the old way they were doing it with oauth 2.0 which is a really good thing to see so that brings us to the end of our pretty whirlwind uh tour of oauth and open id connect like i said there's a longer version of this talk that i recorded last year i created a short url you can go to oauthacademy.comtalk if you want to see that you can also hit me up on twitter i'm at in barbatini i'm happy to answer any questions you have about oauth and open id connect if i don't know the answer i'll uh i'll try to find some information for you or at least point you in the right direction

Channel: GOTO Conferences

Views: 8,400

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, Programming, Software Engineering, GOTOchgo, GOTO Chicago, Nate Barbettini, OpenID, OAuth, Cobbler, OpenID Connect, OAuth 2, Security, Privacy

Id: sSy5-3IkXHE

Length: 18min 44sec (1124 seconds)

Published: Mon Oct 12 2020

Reddit Comments

[u/sophiecustura]

Unravel confusion around how OAuth works with this #GOTOchgo talk by u/nbarbettini

Nate will break down #OAuth and OpenID Connect in plain language, explaining when and how you should use these standards in your applications

[u/crccheck]

I haven't watched it yet, but this looks like an updated/condensed version of https://www.youtube.com/watch?v=996OiexHze0