OAuth 2.0 and OpenID Connect (in plain English)

okay, let's get started, welcome everyone, my name is Nate and today I'm going to talk about OAuth and Open ID Connect. I worked at a company called octa up in San Francisco and I do a lot of web security stuff and I work on just making it easier for developers to do authentication and authorization in their applications and from talking to a lot of developers I realized that a lot of people You've heard of these authentication protocols and OpenID Connect, but a lot of people really haven't. You know what they are or maybe you understand them a little bit, but you don't really don't understand them completely, so just as a quick survey, who here has at least heard of Open ID Connect or, oh, awesome, how about you? you'd feel like you're an expert at it or you actually understand the protocol at a pretty good level, not me, not me, these are pretty difficult protocols to understand, especially for some reasons that we'll get into in a second;

There is a lot of confusing information about them online. So my goal with this talk is to just put aside the jargon, put aside the technical talk and try to ex

plain

how these protocols work in the game, try to make it really easy to understand and let's get into some of the technical stuff. today because we have a little extra time, but if you have any questions at the end, don't hesitate to ask. I'm going to try to make it as easy to understand as possible, so the first thing we're going to do is Let's talk a little bit to start with a little bit of history to come because it's helpful to set the stage and understand where these protocols come from and why they were built the way they are. way they are and that will inform more or less. how we understand how they are supposed to be used today, so if you are interested in the slides or the video of this talk, it is available and will be available on my Twitter at the end in a 10 bar batini and if you want to follow all my team, we publish a lot of good content like this, you can follow it on octave, okay, so let's start even before we talk about OAuth and OpenID

connect

.

I want to set the stage and talk about what's most important. basic type of authentication you can do on the web, this is the simplest case. I call it simple login or sometimes it's called forms authentication and this is just a simple example of where you have an email and password or a username and password form. on a website the user enters their information and your backend website code will like to go to a database somewhere, search and see if that username and password actually exist, if so, verify that the password matches, hopefully by hashing the password. to make sure we're not like storing the password in

plain

text, looking up the users information and then usually what would happen is the app would place itself as a cookie in the web browser to track the user and say, "Hey, this user is already logged in." they are associated with this particular session ID or something and we are logged in as a user now, that's basically how the web authentication started. in PHP or in my case classic ASP, really bad code that I never want to see again for 15 years, but you can do it on your web server if you want the industry has moved on a bit. to do this in a local way and I'll explain why, so this has nothing to do with OAuth yet, but I wanted to set the stage to explain what we're going to compare to this. is like the simplest use case, there are a couple of disadvantages to doing authentication within your application in a local way, as I just described.

The downside is that when you do it that way, you're on the hook for all the security and handmaiden that goes into maintaining an authentication system, so it's just code from your server going into a database somewhere. place and you know, making sure the user's password matches, then you need to keep in mind when best practice and security is to change the password. hashing or storing user information securely or you know HIPAA is on the way or now gdpr is on the wire, you need to be aware of how these things change and there is quite a bit of maintenance involved to make sure your ten times are still working , so you run the risk of giving away the punchline a bit.

Ooofff 2.0 and open then

connect

are some of the industry best practices that the industry as a whole is moving towards to try to make this problem a little easier to solve, but I'm getting a little ahead of myself, so Let's first explain how these protocols work and then I'll come back to that, so I want to acknowledge that there is a lot of really confusing information about OAuth online if you try it. Google what to do or how Open ID Connect works or how I use OAuth 2.0, you're probably going to find some extremely confusing information when I started learning about this a couple of years ago when I got into the web security space that was.

Really confusing for me too and I still get confused sometimes even today. I think the guys who wrote the specs are still confused too. What you will find online and why it is so confusing is that, mainly for two reasons, there is a lot of terminology and jargon that is very dense, very obscure and very specific to op 2.0, so the problem is that if you are a newbie or you don't really understand how this works yet and you search on google to try to figure out how it works. works, what you'll probably find is a lot of information that will talk to you like you already understand all these terms, you already understand all this jargon, but if you don't know what those things mean, you have no idea what they're talking about. and that can be very confusing.

The other thing that's really hard when you're trying to learn this is that there's also a lot of misinformation online, so if you Google some of these terms, chances are you'll find it's probably like a Stack Overflow post from guys who explains how to use OAuth in a certain way and then the next result will be like someone else's blog post saying they're doing it wrong and you should really do it their way and then the third result will be like a completely different blog post that says that they are both wrong and that you shouldn't do it that way at all because that's the worst thing you can do, it's obviously very confusing when you're learning this, you're wondering who's right, why when we have a specification that otherwise , I should be very specific, why do we have so many different interpretations of how to use it?

Obviously, that doesn't happen with HTTP. There's a pretty correct way to use HTTP and that's it, but with Unfortunately, OAuth has all this kind of leeway, there's a little bit of confusion in the specifications, which makes it very difficult. I just wanted to acknowledge that if you've ever felt confused, overwhelmed or intimidated by these things, I'm not alone, almost everyone has my goal today is to try to make it a little less intimidating and a little less confusing and you can let me know at the end if It makes a little more sense, so let's go back in time. take our time machine and go back in time about 10 years, like 2006-2007, this was a long time ago, especially in the Internet years, this was a long time ago because in 2006, let's say, we didn't even have smartphones, that it was like new, but the iPhone came out like Oh 7.

I think this was a long time ago back then, although just like today, apps and websites had several different use cases that they might have to deal with in terms of login authentication. authorization I'm just going to use the term identity as a general term for authentication, authorization, login permissions, that kind 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, you could probably fill in some form and some cookies or something, just log in with a username and password, that's pretty simple, we also have some apps that need to do a login single or SSO. and that was normally done with a protocol called sam'l and today it is still done very often with a protocol called sam'l.

Also, the sam'l protocol is very good for this type of single sign-on use case, which is basically where you have one account on one system that allows you to log in or access several different systems. This is very common in similar companies where you have a single master account or you have an Active Directory account or an employee account that allows you to log into several different systems and sam'l is the protocol that makes it work under the hood, the protocol sam'l works, it has a reputation for being a bit difficult to work with as a developer because it's pretty, it's quite dark, even darker than ooh, it's very very dense, but it works and was used back then just like it is used today Today, there are a couple of new use cases that were just starting to appear on the scene about ten years ago.

However, that was new, so one of them was mobile apps, like I said, mobile apps, smartphones were brand new, the idea of ​​apps and the App Store was brand new, so there is a set completely new of use cases where we want to be able to log into a mobile app but want to stay logged in, you know after closing the app, most likely how do you keep a long session alive on a device. Is it used as a cookie that doesn't really work well on devices? It was a new field, it was brand new, so we didn't really have a good solution for it right away, other than something called a use case called delegated authorization, which probably sounds like the most boring academic thing you can imagine, but this is In fact, what I'm going to focus on here, delegated authorization is an interesting use case that is also the genesis or where it came oh oh oh oh out of the protocol, so despite sounding very boring, this is exactly in what I'm going to focus on, so The delegated authorization problem is something that, despite seeming very boring, is something that you probably interact with on a daily basis, maybe even today, and you haven't even realized, 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 let them see your public profile and like your birthday or something, but it won't let this app post a Facebook on your behalf, who's ever seen that screen? Same thing with Google or Twitter or whatever, it's a very common pattern on the Internet now, but it wasn't ten years ago, not even about ten years ago that pattern where that pop-up or that message appears and you click. Yeah, and let's say now you probably have like 15 strange apps that are connected to your Facebook account or something that you don't even realize that pattern is oh oh ah, so if you've ever clicked YES on that message, you have already used it.

OAuth maybe you didn't even know it, but let's talk about why it was invented a long time ago, like I said about ten years ago, there was no good way to solve that problem, there were only bad ways to solve that problem, this is a kind of 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 to do it, but at that point Yelp did something. that's pretty common at the end of your signup flow you said hello, just thanks for signing up for Yelp, you wanna know, spread the love?

Send a referral link or invite link to all your friends to sign up for Yelp too. It's a brand new startup, so they're trying to get you to meet as many people as possible to use the service. The way they did it was to say, "give us your Gmail email address and also your Gmail password in case they weren't clear on what they were asking for, it's a little small here on the screen, but it says in parentheses the password that you use to log into your Gmail email in case you weren't sure what password they wanted you to give them, then what they're basically saying is like, hey, we'll log into your Gmail account for you, we'll take all your contacts, send them all an email and then log out of your Gmail account throw away your password, we promise we won't do anything wrong with it and then we'll go on our merry way, so in case you get caught. ask this is really bad, you shouldn't do this, you shouldn't create something that does this and you shouldn't use something that does this with your Gmail because for a lot of people their Gmail account or their Yahoo account or whatever their. kind of primary email account is usually the key to the kingdom for a lot of other things that so your bank, you know, password reset flow probably goes back there.

Your Bitcoin Coinbase password reset flow probably returns there. Hopefully,you have two factors set up on these accounts and stuff, but this is a very, very bad idea to just give people your information randomly. your Gmail password, especially since back then Yelp wasn't the huge billion dollar company it is today, they were like some startup I would never have heard of, so this is really bad, like I said, I'm not trying to bother them too. To a large extent, this is just a very good example to illustrate what the problem was back then and how they didn't have a better way to solve it then, we have a better way to solve it now and today.

I would use that flow I just described a lot. before a pop-up window appears saying that Yelp wants to access your contacts. Are you sure you want to allow this yes or no? As a sort of ironic side note, there is 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 allow you to add all of your bank accounts and you see them all on one screen when you set up your bank accounts. to give them your bank username and password to do that and the reason is that banks haven't adopted OAuth yet, they are still using this really nasty old way of doing it so you know your information is really safe when you bank online.

That's great, so let's talk about how they 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 going to talk about it at a really high level and then we'll progressively go down and talk about lower and lower levels of how this works, so we start with a user like me or you saying, "Okay, I trust Gmail. , maybe trust 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 being able to delete my email or, you know, go searching for Google Photos at night on Google Drive or whatever, so, what would we do? today we would have a button in the app on Yelp or whatever that says connect with Google or authorize with Google or a link or whatever, what happens when the user clicks on that button or that link is the user that is placed in what is called Sometimes an OAuth flow is 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'll look at this diagram five times and you'll probably get I'm really tired of looking at it, but this diagram is going to illustrate on a high level how this works, so let's say the user clicks on the connect to Google button or the link to Google button, which What will happen is that the user's browser will be redirected to Most likely a Google domain accounts.google.com and on that Google domain they will be asked to log in, so they will probably enter the email and password, although that's at least a little better because now I'm at least giving my password to Google and not Yelp or anyone else, so I should feel good about logging into Google.

I can see that in the address bar it is actually a Google domain that is presented to me, assuming I log in successfully, a message appears saying Hello, this app. 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 must give explicit consent to anything they are granted access to. That's important so that you don't get tricked into accepting something and you don't know what you're accepting and then assume that the user clicks Yes, they can always click No, in which case we're done, nothing more interesting happens. , but if the user clicks Yes, then the browser will react once back to the app back to where it started to a special place in the app called a callback or redirect URI.

I'll talk about that in a second and with a little magic that application will be allowed to continue. talk to some other API, say Google Contacts API and say hey, normally I wouldn't have access to Nate's contacts, but I have this special magical thing that tells me I can have that now, click the Yes button, like this There's still a little bit of magic in this diagram, but we're going to eliminate the magic in a second by talking about all the different terminology that goes into this, so here's a lot of terminology for you in the waft type of panorama. 2.0. side note, by the way, there is an

oauth

1.0, but we won't talk about that today because for all intents and purposes it's no longer used, it's just deprecated, no one really uses it. oo-ahh 2.0 is widely used on the internet today, so in our terminology we have a lot of terms and slang that basically just rename things we already have names for, which is a little confusing, but we'll go over them everyone here, so in a lobster quenelle we have something called resource owner, which is just a very fancy way of talking about you or me, the user who can click Yes, who is actually sitting at the keyboard, who owns the data that the application wants to access, so in this example that I will continue to use 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 it. You know, yes, I allow this application to have access to this data. The next term we need to look at is something called customer. this is just a way of referring to the application that we have been using Yelp in this example we will continue using Yelp Yelp would be the client, in this case the application that wants to access this data basically we also have something called authorization server the authorization server is the system that I can use to say yes, I authorize this permission or I authorize this to happen in this case that we have been using, this is account.google.com where I can sign in to my Google account and click yes, I consent, yes I agree, that is actually separate from the resource server which is the API or the system that actually contains the data that the client wants to access, so in this case we will call it Google Contacts API . is the system that actually contains my contacts, sometimes the authorization server and the resource server are the same, sometimes they are merged into the same system, but many times they are separate, so the central point of the entire flow Alois is for the authorization server to return to the client, the point of doing that wait back and forth is to get something called the authorization grant and the authorization grant is what basically proves that the user has clicked Yes, I give my consent. at this permission level or I allow you to have permission for these things.

I mentioned this a little before, but when the authorization server redirects back to the client application, it needs to know where to redirect again and that sometimes calls. a callback sometimes called a redirect URI is basically where should I end up at the end of this flow if the user clicks yes, where should they go next and I mentioned how granting authorization is the goal of this. everything flows well on an even higher level, what the client really needs is something called an access token, an access token will be how they will use the key to access the data that I granted them access or permission to. on the resource server, as you'll see in a second, the client will eventually get something called an access token that will allow it to do what it needs, so let's go through this whole flow again and add some of these bit terms. little by little, so let's start on the client with me, the resource owner is probably on the client's website and I click on the connect with Google button.

What happens is that I am redirected to this authorization server which is accounts.google.com. in this case, but it could be Facebook's authorization server, it could be an octa-hosted authorization server, it could be someone else right at the beginning of this flow, since the client is redirecting to the authorization server, there is already some passing type of information. of configuration information that the authorization server needs, so it says hello when it's done, assuming everything was successful. This is where I want it to redirect again at the end, so we have to pass that redirect URI at the beginning.

We also have to give Es some other information, such as what type of authorization grant we want. There are actually a few different types of authorization grants and I'll get into that a little bit later. In this case, we will use the most common type, as a simple example. which is what is called code grant or authorization code grant because we are requesting a code. This is sometimes called an authorization code flow and in the end, as you'll see, we'll get a code, but I'm getting a little ahead of myself. from myself, so the authorization server then asks the user for login consent for that permission, everything good is redirected to the place specified at the beginning, the redirect URI and is redirected again with something called authorization code because that's what we requested at the beginning now. the client can't really do much with that authorization code, in fact there's only one thing the client can do with the authorization code, which is go back to the authorization server one more time and say "hey, you just told me send".

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 will say: "sure, let me make sure." that code is still valid it hasn't been forged or you didn't invent it or something and assuming that's the case the authorization code is still valid the authorization server says ok client here's your access token and finally the client can do it. What they really want us to do first is go to the resource server, maybe google.com contacts, and say, "Hey, I want to access Nate's contacts." Now normally the contacts are google.com and say you can't access Nice. contacts, who are you, but because the client can attach this access token to the request, contacts are Google com?

It will say ok, normally I wouldn't let you access this information, however, you have this access token that proves that Nate said. it's okay for you to access that information, here you go, if the client tried to do something else, like maybe not get my contacts back, but delete all my contacts, hopefully the contacts, not the Google comet, it says okay, you have an access token, but you don't. it means you can do whatever Nate said, you have access, maybe read-only access to the contacts, you can't delete them or you can't look at their location history and see where they've been or whatever, so this is basically it this flow here this is it the rest of this talk basically we are going to talk about slight variations or slight details of this flow but this is it so we are making some progress I talked about how the access token basically grants access to the client to do one thing specific, but how does the client specify what they want to do?

We need some way to be able to say what the client wants to do, like read my contacts but I'm not trying to get access to delete my contacts, it wouldn't be very helpful if it was an all or nothing black and white thing that we don't want to have, like no permissions or all the permissions we want. having some way of being very granular having specific permissions that we can turn on or off or request and add a little bit more terminology to it, that's what ooofff calls this idea of ​​scope or scopes. The way this works is the authorization server. a list of scopes that you understand, so it could be like thought contacts read thought contacts write you know email that reads email dot remove basically any kind of permission that makes sense in the system and then in the application client when they start this flow, they say okay, I don't care about most of those scopes, I don't need to read their email or delete their search history or whatever, I just want the scope that gives me access just to read their contacts and That's all or if they need to do it. more things, they could request multiple scopes depending on the level of permissions they need to have with my data and then on the other hand, that list of scopes, that list of permissions that the client requests, is then used by the authorization server to generate that screen, that consent screen that is presented to the user that says Hi, Yelp is asking for permission to do XYZ ABC, are you sure you want to allow this and give users an explicit ability to consent or not to that particular? access level or that particular list of scopes in the case of Facebook, they changed their authorization server recentlyto be really explicit about letting you know if an app you're giving access to can post to your wall because at first it wasn't very clear, it was like do you want to allow this app to connect to your account, yes or no, and if you do click Yes, you weren't really sure, does that just mean they get my information or does that mean? they like to spam my wall because that was really annoying and people got really upset because Facebook made it a lot more explicit and granular so you have to do it if you're an app that connects to Facebook, if you're a client you have to do it.

Say I specifically want the scope that allows me to post on their wall or not and then on the consent screen it's very clear to you, which is good, so let's look at this diagram one more time, not much has changed here except to the beginning, the initial. request to the authorization server, the client specifically lists all the scopes, all the scopes separated by spaces that they must have against the user or for the user, in this case let's say this Yelp app only wants to access my public profile and my contacts . I'm simplifying it a bit here because Google scopes tend to be like very long URL strings, but this is the general idea, so what will happen here is because the client requested the scope profile and contacts, that's what use to create this consent screen and then after the whole flow is completed and the client exchanges that authorization code for an access token and then uses that access token to call some API whose access token itself is limited or has scope. exactly what scopes were requested at the beginning, so this access token, in other words, coming out of this flow, has a specific scope to the profile contacts, that's all it means that Yelp, the Yelp app, doesn't was able to turn around and then send some other API request.

I like to know the Google Calendar API or a delete request to my contacts or whatever because the access token, although valid, is not intended to do those particular things. Well, any question so far we've gone through quite a bit of terminology. big question so the question was why do we have these two things? why do we have to get an authorization code and then exchange it for the access token? Why don't we just use the code or why don't we just get the access? token immediately why there is that extra step is a big question.

I swear I didn't put you in the audience because that perfectly prepares me for what I need to talk about next, so it's a great question. There is a specific reason we need to do this extra step why we get a code instead of just getting the token right away and I'm hinting at it here with some of these lines being continuous and some of these lines being dashed but we need to talk about which means having a back channel and a front channel, so this is not OAuth specific terminology, it's more of a network security terminology, but we have the idea in networking of having a back channel or what is considered a highly secure communication channel and a front channel which is a secure channel but a little less secure.

I'll explain what I mean, so when we talk about a highly secure channel, well, if I have my server code running on my server that only I have access to and I make an API request or something HTTP. request from my server to another server like Google API for example, and that is done, you know, HTTP, it's encrypted with SSL, no one can intercept that communication, it's highly secure, that would be considered what you would call it back channel That goes from the mice, my back-end. server to some other API or some other system a front channel your hand is kind of like your browser where your browser is secure, but there are some because of how browsers are built, there are some loopholes or there are some places where things can leak from the browser What I mean by this is let's imagine if I'm creating a website or a web application, I want to keep a secret password or a secret key or something in my web application if I put it in the Technically, HTML or JavaScript of my application web, someone could just right click on view source, look at my raw code and see it right there if they really want to investigate or they could open up the network console or chrome dev tools and see what. my JavaScript is potentially changing what's happening on my page, so because of things like that or just someone could be looking over my shoulder and see something that's on the page because browsers are considered a front channel;

In other words, we can trust. the browser, but we only like to trust it as much as we can, not completely trust the code running on our own server, but not completely trust the browser, so as you'll see here, we're going to go through this flow once more, since you'll see here the way this flow is designed, including why we have to get an authorization code and then exchange it for a token, it's designed to take advantage of the best things about the front channel. and the best things about the back channel to make sure it is highly secure.

I'll explain what I mean, so let's say we have a client going to the authorization server. We have been through this before all these things are happening in the front channel, what I mean by this is that all of these are just full page redirects in the browser that we have, like in the outgoing request here we have the redirect to the server authorization, the things that we are passing to authorization. server the redirect URI what type of response do we want all the scopes we want are all passed through the browser this is usually like the query query parameters request query parameters, so technically if someone was looking over the shoulder if you're looking at the address bar in your browser you can see this stuff, it's not secret but it turns out it's okay because if someone sees the scopes we're requesting, yeah, who cares if someone sees what redirect URI we are? coming back to the end, who cares because we're going there anyway, not that it's a secret if you notice that the return from the authorization server to the client is also happening in the front channel.

I've done the whole front. pipe requests in solid lines here, that means the authorization code is also transmitted through the browser via the front-end channel, which means it's usually also in the query parameters of the request, so if you really look if you squint eyes as requests occur in your browser You can see the code in the address bar query parameters, which means that the authorization code returns to the redirect URI to the callback through the browser. However, the next step happens in a side channel, so the reason we do it that way is because let's say someone was intercepting your browser requests or maybe accidentally installed a malicious toolbar like something like in your browser and was watching your network requests, well, someone who had had the logging job who might like that.

Requests would be able to see the code as it appeared in the browser because it will be like a forward slash. The callback question mark code amounts to something technically, maybe they could steal the code, take it themselves and then try to advance it in the exchange and try to get it. their access token before I could write, but it turns out that they can't do that because the exchange happens only in the back channel, it doesn't happen in the front channel, so the token exchange happens when the application, the client takes that code . it makes a back channel request from the backend server code to return to the authorization server, but that doesn't happen through the browser and again, that's for security, so we're posting that's an HTTP POST, we're posting that authorization. send the code to the authorization server along with other information, such as a secret key that only the server knows, meaning that even if someone stole the authorization code, they wouldn't be able to make that exchange request and try to get 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 never want that secret key to be in the browser because if it was broadcast in the browser we don't know if someone could have stolen it, so we do it only in the back channel of a system where we can basically rely on our own server code and the communication with the resource server using access is also usually not done only in the back channel because once the application has an access token, the access token is generally considered sensitive information.

If I broadcast the access token to the browser, someone could technically steal it and then they could do whatever they wanted. with that access token, whatever its scope, 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 take advantage of the best of the front channel. and the best thing about the back channel, what I mean by this is that the front channel here is used to interact with the user, so the browser is used to interact with the user.

Present them with the login screen. Present them with the consent screen. All those good things. what a browser is really good at, but since we can't completely trust the browser with secret keys and things like that, we let the last step of the exchange flow happen in the back channel, where it's a system that we trust, yeah. Yeah, exactly, so the question was, does that mean we had to do something initially to set up with Google to get that secret and that key absolutely? So let's take a look now that we've done it, we've seen this diagram quite a bit. a little bit this is helpful to understand how it works on a high level let's look a little bit more raw at how this actually works and I'll definitely answer that question as well so if you were to look at the link or the button that you click that says how to connect with Google or link to your Google account here is actually where it would go this is what your browser is redirected to is an address on the authorization server that you then pass a series of parameters or some configuration to so I talked about some of these, already the redirect URI, the scopes you want, the responses, something you configure once with the Google authorization server in this case and then we usually pass something called status which is just like a text value that is sent and then it comes back at the end, but let me show you.

I'm going to shift gears here for a second. I'm going to show you what it looks like to set one of these up there. Come on, let's say I wanted to. I'm creating the next Yelp and I want this to work. I want people to authorize their Google account so they can have access to their contacts. What should I do? It's that I would have to do a time configuration step where I go into Google, I go to the authorization server and I say I'm going to create a client and when I create a client I get two things: something called client ID, which is actually, this value that you can see here is a very long string and I also get something called client secret that is not shown here because it is very sensitive data, so with that client ID and client secret that was what identifies me to the server of authorization, so the client ID is passed along with the initial request that is in the front channel because the client ID is not confidential, it only identifies the Yelp application, the client secret, on the other hand, is basically, as my secret key, this is what I use in the side channel request during the token exchange step and I'll show you how it works in just a second.

What I want to do is show you how this kind of thing works. This is seen in the real world, so let's say I wanted to try this because it can be quite difficult to get this to work the first time because you have to make sure you have all the parameters set correctly and stuff. I'm not connected to Wi-Fi, apparently I created a tool called OAuth debugger comm that makes it a little easier to test this stuff and see what's happening in a second, what's not working right now could be because I'm connected the wrong Wi-Fi let me double check this or is it because I'm giving a demo and the demo gods said it's not right today so it's my Wi-Fi oh cool try Ethernet instead sure, Perfect, thank you, it was the wife.

Thank you very much, so where was she? So I built a tool called OAuth Debugger, try it in the OS debugger. Basically it makes it easy to set up the request and then see if it worked and then once you know it works you can I can take the debugger out of the loop and put your relocation in there and everything should work,so I'm going to use this to demonstrate what it looks like to make a request against Google and see what happens, so this is basically at that point from Google from the console I'm going to request the scope profile which just gives me basic users profile information. test so far, which is a response type code, which means I will receive an authorization code from the authorization server and let's try it.

What's going on? It will ask me to log in. Notice that my URL here is accounts.google.com, so we're on the authorization server. I'm going to log in since I logged in recently. It probably won't ask me to enter my password and that's fine. we came back to this because the redirect URI that I specified here temporarily was my debugging tool, it came back to my debugger and you can see it here if you squint, you can see the authorization code here in the address bar or you can just see it's here, so this is the authorization code that we received from Google, as I said, this is not very useful except to perform the next step, which is to exchange it for an access token.

Now you can't do it through my tool here because that would require sharing your client's secret with my tool and you shouldn't do that with anyone, even if you trust me, but I'll show you what the next step looks like, getting my slides back, it's okay so this is basically what you just made a demand if the user clicked no I don't consent to this or maybe you didn't set the parameters correctly something went wrong you will get authorization the server will redirect you , an error occurred, but we did it. everything correctly and I clicked Yes, so we got a code which is what we requested at the beginning.

Now the next step, like I said, is to exchange that code for an access token, so what that would look like, that's the wrong way, well, that's what it would look like. It looks like it's an HTTP POST to the authorization server on a different route called token endpoint or token route and we basically just send a request that has the code we just got from our client ID this time to include the client secret , which is that kind of really sensitive data the secret key that we just need to keep on the server and then we just say hello authorization server.

I just received this code, but I really want a token, please give it to me and assuming the token, the code wasn't made up or forged or something. that's exactly where you would come back, you would get a response that says here's your access token, it's valid for so many seconds, maybe five minutes or an hour or five hours or whatever makes sense and then the client finally has what they want. what you need, which is an author access token that can be used to make a request, so that request can look like this, maybe it calls 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 it really does is just say that it's okay for clients to make a request through some system to some API that includes that token in the request and then relies on that subsequent API to say, "Okay, I need to make sure this token is valid." They didn't just invent this token, they didn't invent it, it hasn't expired and it actually has the scope to do what they're trying to do. do it if this request was like you know delete contacts hopefully the API will reject it even though the access token was valid but assuming all the checks and all the validation works then basically the request is approved you have success 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 continue like that, so I mentioned that there are a couple of different flows or a couple of different ooofff grant types than the ones that we just talked about. authorization code flow or this type of authorization code grant where you get a code back, that's why it's called that and it uses both the front channel and the back channel together to create a really highly secure method of exchanging this information.

There are other ways. to do that there is something called 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 above which is skip that exchange step just send me the token back from the authorization server don't give me a code just give me the token and that is used 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 happens sometimes when for example you have a pure JavaScript application, like a pure reactor pure Angular application that has no backend, maybe it has some backend API that it's calling, but it doesn't have a backend server that's actually like to render. the page and has the ability to run some backend code, so in that case, if you have a single page static application written in JavaScript, you don't have a backend pipeline, so the only thing you What you can do is do all of this in the front channel.

I'll show you an example of that in just a second, but I wanted to cover the other two streams that are sometimes used. There is one called resource owner password flow or resource owner password credentials flow. It's quite complicated and there is something. called client credential flow, those two flows are back channel only, so they don't involve the user's browser at all. This is basically just your code, your backend server code, which posts a message to the authorization server and says: Hello, I have got these credentials just give me an access token right away, they are not, they are not used as often as the first in the client credential flow, sometimes used when you're doing machine-to-machine or service-to-resource owner communication.

Password streaming is sometimes used to make older applications work correctly, but it is not the recommended approach for new applications. I can talk more about that if you want a little bit later, but I want to show you an example of implicit flow which again is the 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 use the back channel and use the authorization code flow, which is what you would do in most web and mobile applications, but if you are in a single page application that you don't have access to, which What you can do is notice that all these solid lines go to the authorization server instead of response type code, we are saying response type token, which means give me that access token immediately, you don't give me a code that I have to exchange, which means that upon returning from the authorization server we simply get the access token immediately.

We don't have to do that exchange step and then we can go talk to a resource server with that access token, all completely in the front channel, so as I mentioned before, this is considered a little less secure because it doesn't. you have that additional security that the exchange step occurred on a secondary channel, you don't have the security that the token is not exposed to the browser because obviously the token is directly exposed to the browser and that's fine if you do it without having a single page, this is sometimes the only way to do it and may make sense in some situations, you just need to be aware of the security trade-offs you are making and you need to ensure that there is no way for the token to be stolen from your application just good good security overall okay I think we have a question here oh it looks like it's already been answered if you have a question on the webcast you can enter it and I'll come back to that so let's revisit our time machine but we'll move forward a little couple of years ago, so we were in 2006 or so and we saw how the Olaf protocol was invented to solve this delegated authorization problem where I just need to like basically exchange permissions between systems over the Internet.

If we fast forward a couple of years, the OAuth 2.0 protocol was adopted as a huge success, it was very popular in solving this problem, which is incredible because the large number of people who adopted it became. as a widely used standard on the Internet, the problem was that it became a two or two used standard on the Internet, it sort of became a victim of its own success in a way that it wasn't. People started using it not only for delegated authorization problem, but also for all these other use cases, like mobile apps and sim, just web login and single sign-on and all these other things.

Does anyone remember when the Facebook login button first appeared? It was like 2009, maybe, but before the Facebook login button the idea that you could log into a site with just your Facebook or Google social credentials wasn't a thing, it was a new idea. I think it was like 2009 2010, well, if you look under the hood, The way Facebook created that blue Facebook button login and/or Google created the Google button login that is kind of ubiquitous in the whole web now is that they just used OAuth that they just use OAuth under the hood because they said hey ooofff is really popular, it solves these news cases very well and why don't we use it for this authentication use case as well?

So we end up in this situation where Olaf is used for the authorization that it was originally created for and it is also used for all of these authentication use cases as well and unfortunately Oh F was never designed to be used for authentication and I know that It sounds like maybe I'm splitting hairs, it's a bit of an academic difference, but there is actually a big difference and there are reasons why you shouldn't use OAuth for authentication, this is why it tends to It can be so confusing to read about OAuth online because if you just go to a random site that talks about OAuth half the time they talk about using OAuth for authorization for permissions which is originally what it was for and half the time they are talking of using it for authentication, which in my opinion is a hack, is not what the protocol is for, so let me explain why using OAuth for authentication is Bad because in ooofff there is no standard way to get users information , so if you think, let's say 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 your email is. address what's your name who just logged in that would be useful to have ok or authentication was designed for permission scopes that you care about, like if your access token is limited to one particular thing, you don't really care who you are, so there is no way for the OAuth protocol to get information from users, which means that when Facebook created the Facebook login button and Google created the Google login button and Twitter, Microsoft and LinkedIn, everyone built these social login buttons and used OAuth under the hood for it, everyone had to add their own custom tricks on top of OAuth to create some way to be able to get information from users and some other things that are just missing, so sometimes it's so confusing reading about this online. all of these implementations ended up being a bit different, they're actually not at all interoperable, this is bad when we have a standard, we expect it to be super interoperable and used the same way everywhere, so because of this issue due to the kind of simulation that is overused for this authentication use case, some really smart people went back to the drawing board and said okay.

Oh the authentication works great, it solves this delegated authorization problem very well now a bunch of people are using it for the authentication is not very good, everyone is doing their own weird tricks to make it work thanks to Google and Facebook, does it? Why don't we try to add a little of what's missing? Oh, authentication for that authentication use case, why not? we just added 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 there, so out of that effort came this protocol called Open ID Connect and it's actually not even there .

It's 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 these other additional things and ready, so open ID Connect is It's not really new, it's just an extension of OAuth 2.0, specifically what Open ID Connect adds in October We know that to solve these problems or close the gap for this authentication use case, it is. something called an id token and that the id token isexactly what it looks like it only has part of the users information, it represents the id or information about the user and if for some reason the id token you get from the authorization server doesn't have all the information you want you can also ask for that . more user information from something called a user information endpoint that everyone opens ID Connect and that all open ID connection authorization servers implement, so basically what this means is that if I'm using an author, if I'm talking with an authorization server that understands open eddy connect not only can I 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 that opens ID Connect ads and that's another really cool thing.

We have things like the way the specs are implemented is a little more standardized and that's a good thing to make it easier to use, but let's take a look at what it would look like to make an open ID Connect flow. It looks really familiar because it's without trying to make the point many times, it's exactly the same, the only difference if you squint and look very closely at the beginning of the flow, notice how we're still asking for profile scope, but now we're also asking for this other scope called Open ID and that's the only one on a technical level that's the only thing that means that this is an Open ID connection request instead of an OAuth request, if you will.

To get really technical, it's both an Open ID Connect request and an OAuth request. We are just using OAuth to perform Open ID Connect. So what it means to ask for that Open ID scope is that when we go to the authorization server, all the normal things happen. They ask us to allow them access to their public profile or whatever. we return to the callback with an authorization code. We require a code for an access token, but we also retrieve an id token, so we retrieve both and the id. The token can be immediately consumed by the application to understand it or decoded by the application to understand who the user is who just logged in, so we have closed the gap to do authentication, not just authorization, and then the token access we get. as the client application can be used, if we need more information about the user, we can call the user information endpoint to get even more information about the user using that access token, so I want to give you a quick demo of this. an authorization server that supports Open ID Connect and runs through octa up in the cloud so I'll use my 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 thing that ends up like I said, the only thing that identifies this as an OpenID connection request is this open ID scope, that's it, so I'm going to build this request, instead of asking for code like I did. been doing so far, I'm going to request an id token, so this is actually the implicit flow in the sense that we're not going to get the code that we're going to get. the token comes back immediately from authorization and I want to do it just so you can see what that id token looks like, so when I redirect to this authorization server that I built using octa they will ask me to log in and ask a security question. and okay, so we get an id token because that's what we asked for at the beginning and the id token is a long string of gibberish.

It's actually very specific gibberish, but it sounds 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 way that's easy to transmit over the Internet. If I actually copy this id token, just hit here and then go to a tool that can decode it as JSON web token dot IO, just paste it here and you can see what information is inside this id token, so you have a bunch of different properties here, basically just a bunch of information about me, the user, so I like that. my user ID or my email address, things like that allow me to go back to my slides here, okay, so the ID token that you just saw looks like this.

I highlighted some different segments or different fragments of that ID token, but if you decode it if you run it through the decoder that I just showed you, you get something that looks like this, there's a header part, there's a payload part that sometimes it's called claims and you get a signature part as well and the claims are 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 just basic information about the user and then the cygnus is also very important because the signature can be used to verify that the id token has not been modified or compromised or rather changed in any way during the flight, so the client application can actually take that signature , do some cryptographic calculations, and say, "Okay, I know that this ID token has been stamped by this authorization server and is still authentic." It hasn't been modified, someone didn't forge it.

Nate didn't come in and try to edit and say it was someone else or whatever, so it's a really cool feature: the JSON web token or the claim and signature of the JWT standard header payloads and So, like I said, the ID token because that signature can be independently verified by the application without even having to go back and talk to the authorization server. Also, as I mentioned before, I could use the access token I get to return. Call that user information endpoint if the information in the ID token wasn't everything you wanted to know about the user.

I can go call the user information endpoint and say, "Hey, I want information about this user." Here is the access token which proves that I am allowed to have this user's information and I get even more information about the user, sometimes this is like additional things like their profile pictures, things like that, okay so let's check our time machine once again now that we are very fast. Until today, Roth 2.0 is still used for those delegated permissions, delegated authorization use cases, that's correct and now we are also using the right tool to authenticate use cases in mobile applications for single sign-on or for some like you. in simple login cases we can use open eddie can act instead of misusing olaf 2.0 for that and to be a little more specific we would use what we are dealing with permissions and authorizations we would use open nd connect always that we are trying. with authentication sometimes some people get confused and think that because open ID Connect is newer it replaces OAuth 2.0 or it's better or whatever, but it's not like that at all, there are different tools for different jobs, the only thing that Open ID Connect replaces the misuse of OAuth for authentication.

We definitely shouldn't be doing that anymore, but to continue doing similar permissions and delegated authorization, wasyou porn is the right tool for the job, so let's take a look at a couple of similar practical examples. We're almost out of time. I want to show a couple of practical examples of which oo-aah flows or OpenID connection flows should be used for particular use cases because this tends to come up frequently, there is some complexity in the specification about things like which flow is used, in which situation and things like that, but I'm going to briefly go over some of them, so let's imagine we have a really basic web application, we just want users to be able to log in.

This is kind of a review of that simple registration case I showed at the beginning. At first we talked about a simple website that just had a form with an email and password field and just accessed the database or something they were looking for. the users information if we reimplement that with Open ID we connect what we would do is use the authorization code flow to go to an authorization server it can be executed by Google it can be executed by octa it can be executed one that you yourself have created or whatever but use the authorization server to handle the login process and the only thing the application needs to worry about is knowing that it is going to get an access token and an id token from the authorization server and then, As in the initial example, you're probably going to just put it as a session token or session cookie in the browser to track the user and then at the back you'll just retain the access token and the access token. identification of users while they are connected.

The benefit that this has over the kind of very simple forms authentication that I showed at the beginning is that now the authentication system and the rest of the application are a little bit abstracted, they have a little bit of separation, what makes it nice is that then the app and the authentication system can evolve separately if needed, we can maintain the authentication system and update it if things need to change, the security holes need to be closed, all good stuff, Open ID Connect is just a kind of glue. that keeps them together in a form of standard protocol, which is really nice, it seems almost identical for native mobile apps, so if you have a native app on iOS or Android, no one uses Windows Phone anymore, but technically that would do exactly what same.

I would use the Open ID Connect authorization code flow often plus a small additional extension called pkc and test code for key exchange, sometimes called pixie, to do the same thing get an access token get an id token save them on the device you normally store them behind the keychain you already know or 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, which What's really nice about mobile devices is that all the things that involve going to talk to the authorization server making sure you use the correct flow making sure you pixie making sure you do this correctly on each of them as there are some differences between the different mobile operating systems, like in Android, you are supposed to use a specific tab browser control or maybe that has changed now, something like that in iOS, you have to use the Safari View controller, all of that is abstracted in this library in the which Google and some other people worked on called app disabled, so basically you can use app disabled and it does all this right for you all, the other example I talked about was a single page app with an API backend.

This is the situation where you don't have the back channel, so you have to use the implicit stream; otherwise it is identical. you are receiving tokens from the authorization server and storing them locally in your application somehow taking care to make sure you don't do this; make sure those tokens can't be leaked in any way, so make sure you don't have any XSS in your JavaScript and such, but that's a little outside the scope of this talk. There are also other interesting things you can do. This is also outside the scope of this talk, but you can.

If you want, you can use an authorization server like octa to provide a bridge to older protocols like sam'l or other things you don't really want to do within your app, so your app only has to focus on connecting IDs. open and then you. let the authorization server do all the work of dealing with a protocol like sam'l, which is great, but that's all I have for today. If you have any questions, I will be happy to answer them; otherwise, you can leave. I have a couple more resources for you if you want to dive even deeper into how these protocols work, especially how ooofff works.

Go to Oh Ofcom, we've got a free ebook we've published there that goes into great detail about how it works. even more than what I went into today and it talks about things like token like expert and revocation and validation and all that stuff that I didn't really have time to get into and if you just want to play with that if you want to speed up your own authorization server in the cloud totally free you can go to the developer dr. com sign up for an account create as many authorization services as you want play with them totally free super easy super cool so thank you very much for your time.

I'll leave it open for a couple more questions, but otherwise, have a great day.