 Welcome, everyone. My name is Micah Silverman. We're going to get rolling in just a minute or so, but I just wanted to do some quick housekeeping before we get started and before I introduce myself a little more formally. At the bottom of your screen, you'll see a bunch of various widgets that you can use to interact with the presentation during the webinar. You can submit your questions in the webinar by clicking on the Q&A widget there on the bottom, at the bottom. Like I said, my name is Micah Silverman. I'm one of Okta's senior developer advocates, and we're going to be talking today. I'm going to be talking today about OAuth and OpenID Connect. You can see at the bottom of this first slide, you can get me on Twitter at a fit nerd, and you can get all of Okta's developer advocacy team at OktaDev. And just a little quick background about myself. I'm a software developer and a developer advocate. I write code. I speak at conferences. I contribute to Okta's developer blog where we have a lot of tutorials and thought pieces on OAuth and OpenID Connect, and we'll have that available as resources. Now, a lot of times if you search for OAuth or OpenID Connect, or if you're interested in learning about the standards, you tend to get one of two types of Google responses. One is the specifications themselves, which are great if you're building an OAuth service like Okta has done, or if you're suffering from insomnia. Those are great. The specifications are great for that. The other type of hit that you get is kind of deep dive into code without a lot of context for why OAuth, why OpenID Connect, how do they differ, where do they come from. So we're going to take a step back at the beginning here and try to give some context around OAuth and OpenID Connect. In order to do that, we're going to jump back a bit to around 2007 to look at what the web looked like then. So at that point, we had simple login, we had forms and cookies, we had full page transitions. You'd click on a link, you'd go to another page, you'd fill out a form, you'd submit that form, get to another page. That was kind of the state of the art of the web. We did have some single sign-on standards like SAML, but those were really in the domain of the enterprise. If you were a big bank or an insurance company, maybe you were using SAML, but it certainly didn't proliferate out to consumer-facing websites. To put things in context, in 2007, mobile was not solved as a viable platform. So 2007 was the year that the very first iPhone was released, and if you go back to articles of that time, there's probably an equal number of negative articles as there were positive. Lots of articles saying that this was ridiculous, nobody was ever going to spend hundreds of dollars to have a computer in their pocket to make phone calls, who wanted to browse the web on a three-and-a-half-inch screen. So mobile was not solved at this point, and we were just starting to talk about the idea of delegated authorization. Now we're going to talk about delegated authorization a lot, but that conversation came out of the state-of-the-art of the web where you had interfaces like this. This is a real screenshot from around this time from Yelp, and we just started to want to have interactions between different websites. So in this case, Yelp was this hot new service where you could rate restaurants, and Yelp gave you this interface so that you could connect with your friends that either had a very similar interface, you put in your email and password, and Facebook would read your contacts and give you a list of your friends and show you which friends were already on Facebook so you could connect with them, or give you the opportunity to invite friends to Facebook. So these sorts of interactions between websites, Yelp and Facebook are examples, started becoming more important. The problem here was one of access and authority. Once I give my password to Yelp or to Facebook, that's kind of giving them the keys to the kingdom. Really what I want them to do is have read-only access to my contacts. I barely trust them with that level of authority. But in practice what's happening is they now can do anything as me. They essentially can masquerade as me. They could send emails on my behalf. They could delete my contacts. They could look at my Google Docs. That's way more authority than I want to be able to give them. So the question that emerged is how can I let a website access my data without giving it my password and access my data in a very limited way? Now I just want to do a quick check here and make sure the audio is okay. So I'm just going to check in with my producers. Is the audio good or do I need to switch to a different mic? Just let me know in chat. Okay, cool. All right, so now what emerged out of this conversation on delegated authorization, how can I let a website access my data without giving them my user ID and password, is the OAuth and then later on the OpenID Connect standards. But now there ended up being a lot of confusion around these standards. So the confusion comes with a lot of terminology and jargon. This is less of a factor today, but there's a lot of incorrect advice. So you literally get blog posts or other types of posts where people were saying to take a certain approach and using OAuth and OpenID Connect was just plain wrong. In order to understand OpenID Connect, we first need to talk about OAuth. And we're going to see a little later on kind of a spoiler alert that OpenID Connect is a thin layer that rides on top of OAuth. It doesn't stand alone. So even if your concern is only one of authentication and single sign on and identity and you say, well, I don't need to know OAuth. I just want to focus on those concerns and use OpenID Connect. You still need to learn a little bit about OAuth because OpenID Connect builds off of it. And it's often hard to find a lifelike example out on the web. As human beings, we like to deal with analogies and metaphors. It helps us to learn things. And it's hard to find that out when you do a web search. So we're going to attempt to relate OAuth to a lifelike example. And that example is how we interact with a hotel. So the hotel analogy. And it turns out that the way that we interact with hotels maps on to OAuth in some very specific ways. So this diagram here, we have a person who goes and books a hotel. And they interact with the hotel receptionist. Usually we give them a piece of ID and a credit card. They hand us a hotel key and then we go open the room up. So that's kind of the day-to-day interaction we have with hotels. Now more formally in this diagram, a hotel booking system delegates access to me as a guest so that I can interact with the hotel receptionist and get a key and then I can access my hotel room. Now it turns out that the way that we interact with hotels maps on to OAuth in some very specific ways. Three in particular that we're going to talk about here. First of all, there's this idea that with this hotel key that I've been handed, I can only access a very limited subset of rooms, usually one. I can't just go up and down the hall and open any room. I can only open up the room that's been assigned to me. Now in the world of OAuth, we call that scope. And the tokens, the keys that we deal with in OAuth called access tokens also can have limited scope. So that's the first way. The second way is that there's an expiration built into my hotel key. So if I check out of my hotel and I keep the key and I come back the next day, it's a pretty aesthetic, it's built into the key. There's nothing that the hotel receptionist or the hotel manager had to do explicitly to expire that key. It's built into the key. Likewise in the world of OAuth, we have these access tokens and those access tokens also have a built-in expiration. And now the last way that I'm going to touch on that hotels map on to OAuth, it really drives home the point that OAuth is all about authorization, where OpenID Connect is about authentication. And this last point is that the hotel key is what we call a bearer token. What that means is that if my arms are full and I go up to my hotel room door and I hand the key off to my daughter or my wife, they can open that hotel door just as easily as I can. So the hotel door doesn't care who I am. All it's doing is validating the key. Is it the right room? Is it not expired? And then if that's the case, it's going to open up. So likewise in the world of OAuth, when we have these access tokens, they are bearer tokens, and the API that we're interacting with with the access token doesn't care who we are. It's just going to check that the token is valid, that the scope is correct, and that it's not expired. It's also one of the reasons that in modern hotels, those hotel keys don't have the room number stamped on them because if we were to drop that key in the lobby of the hotel and it had the room number on it, then anybody could open our door because, again, the door doesn't care who we are. Now, let's look at the same diagram in the context of an application. And if you notice, switching back and forth between these slides, the arrows and the steps are the same, but the actors are a little bit different. Now, in the case of an app, we have an end user that's like you sitting in front of your browser, you delegate access to Yelp, because you want Yelp to be able to read your contacts. Yelp obtains an access token from Google, and then Yelp uses that access token to interact with an API, in this case the contacts API. So it's very similar to the way that we interact with hotel rooms. Now, with that under our belt, we can take a look at some more formal OAuth terminology, and the third column in this table are our formal OAuth terms. So we have these four actors. We have a resource owner, a client application, an authorization server, and a resource server. Now, starting at the top, the resource owner wants a client app to do something on their behalf. So that's like in the hotel, the hotel booking system is going to enable me to book a room. In the case of Yelp, me sitting in front of my browser, I want Yelp to do something on my behalf, namely read my contacts. The client application needs authorization to interact with an API on behalf of a user. So in the case of the hotel, that's me as the guest. In the case of the app, that's Yelp. So Yelp needs authorization in order to interact with an API, the contacts API on my behalf. Next up, we have the authorization server. The authorization server grants access in the form of tokens to an application. So this is Google granting access to Yelp in the form of an access token. And finally, we have the resource server. The resource server has an API that an app can use if presented with a token. So the contacts API, Yelp can use the contacts API as long as it presents a token that has the right scope and isn't expired. So now, in a more modern app, when we're using OAuth 2, what we're really saying is I trust Gmail. I use Gmail every day. And that's where my credentials for Google are supposed to go. And I kind of trust Yelp. I want Yelp to have access to my contacts only. And so now, instead of a form that I click on, or that I put my username and password in, now I have this friendly connect with Google button. Now, we're going to use the option that's going to enable Yelp to read tokens on my behalf. Now, when we were looking back at these different analogies, like the hotel analogy, you'll notice that there were steps here, one, two, three. Same as with our app scenario. These are the steps that it took to get an access token and to use that access token. Now, in the world of OAuth, we call that the flow. And there are a number of different OAuth flows that we're going to take a look at now. And the very first one that we're going to look at is called the authorization code flow. And we start with that flow because it's, first of all, it's the most secure. It's also the most complex. It's got a lot of moving parts to it. So let's take a look at the authorization code flow. Now, the first thing that happens when I click on that connect with Google button is it sends me over to Google to authenticate. This is where I'm supposed to put my email and password. And so Yelp is not involved in this part of the flow. I'm going to authenticate at Google like I ordinarily would. And one thing to notice is that included in this initial request is a redirect URI. That's because we're outside of Yelp at this point. And when we're done authenticating with Google, Google needs to know where to send us back so that Yelp can continue this flow. So that's why we have this redirect URI. Now, I also want to point out that I said that OAuth was all about authorization. But here we're talking about concerns of authentication right off the bat. That can be a little confusing, and so I want to clear up that confusion. There's an expectation that authentication is happening, but it's out of band of the OAuth flow. What I mean by that is that this authentication may be complex. Maybe in addition to putting in my username and password, I have to provide two-factor authentication. Maybe my password is expired and I have to reset my password. That could all be part of this authentication piece, but OAuth doesn't care about any of that. OAuth only cares about the assertion that it gets back ultimately as proof that I authenticated. So authentication is happening, but it's really out of band of the OAuth flow. Let's continue. After I authenticate, I then get a consent screen. Now, you've probably seen this. Facebook popularized this. The purpose of the consent screen is so that the authorization server can present to you as a user what it is that Yelp, in this case, is asking access to. So this should be human-readable and it should be clear. And in this case, we're saying the consent form is saying Yelp wants to access my public profile and contacts. And this is my opportunity to allow it or not. So this is our opportunity to say, well, you know what? Yelp is asking for too much. I don't want to give them that authority. Now, if you're like my mom, you're going to click on yes no matter what it says here. But hopefully we're a little more discerning because this is our opportunity to say, you know what? I've changed my mind. I don't want to give Yelp this access. Assuming we click yes, this is where Google now uses that redirect URI to go back to Yelp. And what it sends back to Yelp via an HTTP redirect is an authorization code. Now, the authorization code is a one-time use code and it has a very short lifespan. First, you have 60 seconds to use the authorization code before you have to start the flow all over again. Okay, now that Yelp has this authorization code in its hot little hands, it can exchange the authorization code for an access token. And that's been Yelp's goal the entire time. Yelp needs to get an access token so that it can interact with the contacts API. So what Yelp does is it makes a post request to Google to exchange the code for an access token. It also, this is a simplified view of what happens. It sends along the authorization code, but it also needs to send along a secret that had been issued to it by Google earlier. And so now a combination of the secret and the authorization code gives Google everything that it needs to validate. And assuming it's valid, Google is going to return an access token. Now that Yelp has the access token, it can use that access token to interact with the contacts API. And now it can read my contacts and Yelp now has the authority to access my contacts, read only. It doesn't have any authority to do anything else like access my email and it never saw my past further and see what else is going on with this. Now we're going to revisit this flow a number of times. And let's see what we have here. So we're going to add in some more OAuth 2 terminology. And now let's talk a little more deeply about scope and consent because those are intimately linked. When I click on connect with Google in addition to the redirect URI, it's also sending along a space separated list of scopes. Now these are the scopes that Yelp is requesting and Yelp can request any scopes. It could request write access to my contacts. It could request the ability to send email on my behalf. It can request whatever it wants. But Google is going to show all of the scopes that Yelp is requesting and give me an opportunity to say yes or no. So the scopes that are requested and what we see in the consent form are tied together. And it also drives on the point that the scopes that Yelp requests are relevant to the authorization server to Google. So the scopes must be scopes that Google recognizes and then Google is going to present those requested scopes in a human readable form so that we can make a decision. Now assuming that we say yes, everything continues here. We redirect back with the authorization code. Yelp exchanges the code for an access token and then Yelp talks to the back end API, in this case the contacts API using that access token. Alright, let's look at some more terminology. Bear with me a sec. Here we go. Even more OAuth 2 terminology. So we have this concept of the back channel and the front channel. And you may or may not have noticed in the diagrams that we've looked at so far, there were solid lines and there were dotted lines. Now the back channel is a highly secure channel and the front channel is a less secure channel. And what we mean by these channels is the front channel is anything that passes through your browser's address bar. That's what we call the front channel. Anything that's a server to server communication, that's the back channel. So let's revisit our flow here and see when we're dealing with the front channel and when we're dealing with the back channel. And when we click on this initial link, that's the front channel. That is you this initial request that includes the scope and the redirect URI that all happens in your browser's address bar. We also see the consent form from our browser. So that's front channel and Google redirects back to Yelp on the front channel as well. So this authorization code that Google sends back passes through your browser's address bar. Now we call this a less secure channel because there are certain things that can interfere with this interaction. When Google redirects back, if you're familiar with HTTP, this is an HTTP 302 redirect that hits your browser and then the browser sends that request over on to Yelp. The browser does that automatically. You don't have to intervene. But we call it a less secure channel because, first of all, Google has no way of knowing that the correct recipient, namely Yelp in this case, actually received the redirect. So you may have some compromised network or a compromised machine and maybe Yelp never receives that redirect and Google has no way of knowing that. If you heard that beep, that was my phone activating because I was saying Google so much. So there you go. Google is always listening. All right. I'm going to have to turn my phone off, I think. All right. So that's one issue is redirect interception. Another potential issue is you may have a compromised machine. You may have malware or a virus. You may have even a misbehaving browser extension that's listening to what's passing through your browser's address bar and intercepting it. So these are all risks on the front channel. Now we're going to see in a little while and you may have asked, you may have the question, well, why do we go through this whole dance? Why do we have an authorization code and then we have to exchange it for a token? Hopefully that will be cleared up in this conversation about back. So everything that happens on the channel, including getting this authorization code. Now assuming Yelp gets the authorization code, the next thing Yelp does is exchange it for an access token. Now if you notice, this line is dotted. This is a back channel communication. So Yelp sitting in Yelp's data center behind Yelp's firewall is making a post request to Google sitting in its data center behind its firewall. This is a much more secure mode of communication. And that's why we call it the back channel communication. So now Yelp has a high degree of confidence that it's communicating with Google. And because it's a post, the request is a post, the response from Google is going to come back on that same channel. So it's much more trusted. And this is why we have this little dance. Google doesn't return the access token directly to Yelp in a redirect because then the token would pass through your browser's address bar. And if you remember, the access token is a bearer token. So if you have a malicious browser extension that's examining your address bar and that access token comes back through your address bar, now that malicious browser extension has the access token and can use it directly. If, on the other hand, the browser intercepts the authorization code like a misbehaving browser extension, there's not a lot that that extension can do with that authorization code. Because if you remember from before, in order to exchange that authorization code for the access token, Yelp also needs to provide a secret that your browser extension would have no way of having access to. Because that secret that Yelp is using is programmed as an environment variable or in a database, something that Yelp only has access to in its server safely in its data center behind its firewall. Okay, once Yelp has the access token, it can then use that access token also on a back channel communication with the contacts API to read your contacts. Now, tactically speaking, this is what when we click on that connect with Google button, this is what the URL looks like, or this is an example of what the URL would look like. So we're hitting an authorization endpoint and we're passing in, at a minimum, we're passing in these five query parameters. We have a client ID that identifies the application in the service, in this case Google. So with Google and Okta and Facebook and most providers, you can have any number of applications defined. And so the client ID identifies the application. Then we have the redirect URI that tells Google where to redirect back to we have a space separated list of scopes. We have a response type. This is part of the OAuth specification and it just indicates to the authorization server what we expect to get back from this interaction. So what we expect to get back is a code or an authorization code. And then we have a state. The state value is usually a randomly generated value that the application generates. So this would be something that Yelp generated. And the responsibility of Yelp is to generate the state and to validate the state. And the responsibility of the authorization server like Google is to return the state when it redirects exactly as it got it. So it's just an additional check to make sure that Yelp is interacting with Google when it gets a redirect. Now assuming you, when you get to the consent screen, you're going to either click allow or deny or yes or no. And if you clicked no or deny, it's going to redirect back with an error. That's what this top URL is showing. If you click yes or allow, it's going to redirect back with the authorization code and the original state that was passed in by the application. In this case, Yelp. So that's the first leg of the interaction that we've been seeing in the diagram, which is the authorization step. Now we have the step where Yelp is going to exchange that authorization code for an access token. And this is an HTTP post. The content type has to be XWW for URL encoded. That's part of the specification. And then Yelp needs to provide these queries to exchange the code for an access token. So it's the code itself. It's the client ID. And then this is where Yelp provides the client secret, which only it knows. Or I should say it and Google know because Google assigned the client secret. And it needs to provide the grant type. Grant type is synonymous with flow. And so this last 10 slides or so, we've been talking about the authorization code flow. So grant type is required, assuming all this checks out. Then Google is now going to respond with an access token. It's a JSON response, and it looks something like this. It's got the access token itself, an expiration, and a token type, which is going to be bearer. Now one thing, if you have questions, ask questions using the Q&A panel and we'll address them to the greatest extent possible at the end. Now once Yelp has this access token, the way that it uses it is to hit an API endpoint using a standard HTTP get or post. And then it uses this authorization header. This is also part of the HTTP standard, which predates OAuth. So there's an authorization header. And the way the authorization header works is you give it a scheme and a value. Now there are some built-in schemes that you may or may not be familiar with, like basic is a built-in scheme. And if you've ever interacted with your home Wi-Fi router, you've probably encountered the basic scheme. That's where you get that old-school pop-up and you have to put in a username and password. And in the case of your home Wi-Fi router, it's admin-admin or admin-password and everybody knows it because you never changed it. That's basic authentication. But the HTTP specification accommodates custom schemes. And in the case of OAuth, the custom scheme that we're using is the keyword bearer. So bearer with a capital B that must be present, followed by a space, followed by the access token that we just got. And then it is the responsibility of the API now to validate that access token. So the API receives that access token. It's going to validate it to make sure that it's a valid token, that it's not expired. It's going to make sure that the scope is correct for the API endpoint that's being interacted with. Assuming all that checks out, the API will respond with, in the example we've been talking about, a list of contacts, or it'll respond with an error if Yelp was, say, trying to write to my contacts. The Google API would recognize that it hasn't been authorized with that scope, and it would respond with an error. So in using the access token, the client, Yelp, passes the token along. The API validates that token and makes sure that the scope is correct, and assuming everything checks out, it'll send back a response. Okay, so we dove deep there into the authorization code flow. We're going to talk about some other OAuth flows, and we're going to touch on a few of them. We don't have enough time to get into all of the different flows, but it will at least let you know under what circumstances you would use the different flows. And we have a whole bunch of resources at the end if you want to explore some of the other flows as well. So authorization code flow, that's what we just talked about. That uses a mix of the front and back channel as you saw. There's a special extension to the authorization code flow called authorization code with pixie pkce. That stands for proof key for code exchange, and we're going to look at that in some detail toward the end. That also uses a front and back channel, and the spoiler alert there is it's a way to use the most secure flow, which is the authorization code flow in unsecure environments, insecure environments like your mobile apps, your desktop native apps, your single page apps, spas. So this is a technique in order to be able to use this flow in an unsafe environment. The implicit flow is a front channel only flow that has been deprecated. We're going to talk about that in just a second. We're going to look at that flow, but the punch line there is you should no longer use it because the latest guidance says to use the authorization code with pixie flow for your spa apps. Then we have a couple of other flows that are back channel only. One is the resource owner password flow and the client credentials flow. Resource owner password also is a flow that is not generally used anymore. It's still a valid flow, but in your most cases you won't be using that flow for a variety of reasons. The TLDR there is that it requires that you give the username and password, and so in most cases it's going back to that password anti-pattern where you're supplying credentials to a third party. So you shouldn't use the resource owner password flow unless it's a first party app. Finally, the client credentials flow. This is a valid and often used flow. This is for when there is no user. So if you have a microservices architecture and you want to secure service-to-service communication or you have a batch or a cron job, there's no user involved, that's where you would use the client credentials flow. Let's talk about the implicit flow. Just imagine that Yelp has an Angular app, a single page app, and it wants to use OAuth. Well, in the old days the implicit flow was released at a time when there were limitations both from providers and from browser capabilities, and the implicit flow was the best we could do. Now this is what it looked like. We would authenticate at Google. That's good. We would get the consent form. That's good. But because it's a spa app, Google would immediately redirect back to the browser with the access token. Now this presents a couple of problems, some of which have always been there with the implicit flow and some of which are new. So the problem that's always been there with the implicit flow is redirect interception, which we talked a little bit about earlier. So because this is a front-channel only communication, that access token might be intercepted, and then because it's a bearer token, it's kind of game over. So now you might have a malicious app reading all of your contacts and maybe spamming your contacts in a way that you didn't intend. Also with modern browsers, we have a couple of new possible vectors of attack that didn't exist when the implicit flow was first released, and it's another reason why you shouldn't be using the implicit flow anymore. One of those is browser history syncing. So we have these super convenient features in browsers like Firefox and others where we can now sync our browser history, and that's great from a user experience perspective. I can log into, say, my bank on my mobile Firefox app, and then when I walk into my office, I can go over to my desktop and I can pick up right where I left off. Super convenient. And that's because Firefox is syncing my browser history, including cookies and tokens and anything else that might come across. But that increases the vector of attack because now an access token potentially is being synced to the cloud, being synced to multiple devices. It's kind of a black box. I don't know what's really going on there. And so that's just a new vector of attack for these sensitive bits of data like a bearer token that we don't want to leak out. So the punchline here is that you really no longer want to use the implicit flow because it's all front channel. Now the good news for our spa apps is that we have an alternative approach that we can now use in the browser. This used to not be the case. We used to not be able to use the authorization code with PixiFlow in the browser, but now we can and so that's the recommendation. All right. Jumping back into our time machine, we're going to look back to 2012 and identity use cases back in 2012 for simple login, for single sign-on across sites, for mobile apps, and for delegated authorization, OAuth 2 was widely used. Now the problem is that the first three use cases are all authentication use cases and it wasn't what OAuth 2 was ever intended for. So Facebook and others were essentially misusing OAuth and kind of bending it to conform to these other use cases for which it was never intended. So a bunch of really smart people got together and said we need a new standard to deal with authentication because there are problems with using OAuth 2 for authentication. One is that there isn't a standard way to get the user's identity information. So Facebook might have implemented it one way, Google might have implemented it another way because we're outside the scope of the standard for what OAuth was ever intended for. Which reduces interoperability. OAuth gave a lot of flexibility. It introduced the concept of scopes, but it didn't define any scope. So maybe Facebook calls your user profile profile whereas Google would call your user profile user info. So it's kind of like the Wild West out there. Everybody was doing things a little bit differently. So Google and Microsoft and a bunch of other smart people got together and said well, OAuth gets us like 80% of the way there. Let's build a thin layer on top of OAuth and get us the rest of the way there and that's what OpenID Connect is. OpenID Connect is for authentication. It's for concerns of identity and it rides on top of OAuth 2. That's why we spent all this time talking about OAuth before we could get to OpenID Connect because it doesn't exist on its own. So OpenID Connect adds a new token called an ID token. It adds a standard endpoint called the user info endpoint to get additional information about the authenticated user. It introduces a standard set of scopes. So there's a handful of scopes like profile, email, address, phone that are predefined with OpenID Connect and so every implementation including OAuth has to support these scopes. It also still supports custom scopes so there's still a lot of flexibility but now we have a much higher degree of interoperability because we all know we're talking about the same thing and so it's standardized the implementation. Let's revisit our authorization code flow but now in the context of OpenID Connect. We have all the same flows available to us because again OpenID Connect is still riding on top of OAuth. All right, so we kick off the flow similar to the way we did before except now we have a required scope and that is the OpenID scope. That's what distinguishes this from a regular old OAuth interaction. So far, so good. We see the consent screen just like we did before. We redirect back with an authorization code and now here's where things are a little bit different. When Yelp exchanges that authorization code now it gets back both an access token and an ID token and now Yelp has an additional capability which is it can use, first of all it can identify me by name because the ID token has my user identifying information in it and it can use the access token to interact with the user info endpoint and that user info endpoint now gives additional information back to Yelp. Okay, bear with me a second here. Let's take a look now at the anatomy of this ID token. Now another thing with OAuth was in terms of flexibility and the standard is that OAuth defined access tokens but it didn't dictate the format of those tokens. So Facebook might have a different token format compared to Google, compared to Okta. One of the things that OpenID Connect specifies is the format of the ID token. It must be a JWT which is a JSON web token. Sometimes they're referred to as JOTs. I'm not particularly a fan of that. I don't know how you get the ah sound out of the W but that's the way it is. So if somebody says JOT you'll know what they're talking about. It's a JWT. Now the JWT pictured here this long ugly gnarly string. We've added some white space and we've colorized it but it's really just one long string. It's got three parts to it. It's got a header, a payload, and a signature. Now the signature is cryptographically signed and to create the signature we use the header and the payload along with a private key and a signing algorithm and that gives us the signature. To validate the signature we use the header and the payload and a public key with a validation function and that gives us a high degree of confidence that neither the header nor the payload have been tampered with. Now the payload is just valid JSON. It's key value pairs but in our industry we have to complexify everything so we don't call it key value pairs. We have to find claims so the key value pairs are and find claims, those are referred to as registered claims and those are just claims with a purpose and they're usually these three letter claims like EXP is the expiration. That tells us when this JWT expires and the value type for EXP as dictated by a specification must be a long number that represents an epoch time, a number of seconds that have elapsed since January 1st 1970. If this value were a Boolean or an array or a string it would just invalidate the JWT because these are registered claims but you can also have custom claims like name and auth time, those are all custom claims and those can be any valid JWT or sorry any valid JSON. All right, we have about five minutes left and we're going to cook through these last few slides here and then we'll have lots of time for questions. All right, so fast forwarding to today we now have everything in its right place. For all of those authentication use cases, the first three, simple login, single sign-on, mobile app login we have open ID connect and then for delegated authorization we have OAuth 2. So on the left-hand side OAuth 2 is for when you want to grant access to your API and open ID connect is for when you want to login the user and understand information about the user. Now knowing which flow to use when for your web application that would be like your Spring Boot, your .NET, your Node.js when you have a back-end you want to use the authorization code flow the most secure and the most safe flow to use because of the back-channel. Now for a native or mobile app or a JavaScript app like a single-page app you're going to use this special extension which is going to be the last thing that we talk about the authorization code with PixiFlow, PKCE and then for microservices and AP credentials flow. All right, let's talk about Pixi. I've left my favorite for last. So Pixi stands for proof key for code exchange and it's a way to use the authorization code flow in an unsafe environment. If you remember the authorization code flow, the end where we exchange the code for a token that relies on a client secret, a fixed client secret. Now in the world of our spa apps or our mobile apps it's not safe to store a fixed client secret because those can be analyzed and decompiled and parsed and looked at and extracted. So what Pixi does, what the Pixi extension does is it allows us to have a dynamic secret that's safe from prying eyes that's only used once each time we go through the flow and it gives us a way for the authorization server to validate that fixed secret. So let's take a look at it. If you're not familiar with this type of diagram this is called a sequence diagram and we look at things from left to right and top to bottom to get an understanding of how the different actors interact with each other over time. So moving from left to right the resource owner that's you sitting in front of the browser you go and access the client app. Let's say this is an Angular app. Now the client app is going to generate a random value that's going to be our stand-in for the client secret. We're going to call that V and it's going to hash that random value using a standard hashing algorithm like SHA-256. The result of that hash we're going to call $. Now the Angular app is then going to redirect over $. The authorization server stores that hashed value which we call $ and it returns the login form to the user so they can authenticate. Now the next part of the interaction is the standard authorization code flow. So the authorization server after you've authenticated redirects back to this Angular app with the authorization code. We're going to call that alpha. And now this is the point at which the client app our Angular app needs to exchange the authorization code with the client ID, the client secret and the authorization code. In the case of Pixi it's going to use the client ID random value that it generated at the beginning of the flow and the authorization code. It's going to send that over to the authorization server and now the authorization server is going to validate that random value V by hashing it first and then comparing the hashed value to the value that it stored earlier in the flow. This is very similar to the way that we handle passwords in modern identity systems. So Octa never stores your plain text password but when it's presented with your plain text password it hashes it and it compares it to the hashed value. Likewise earlier in the flow we saw that our authorization server stored the hashed value and then later on when it receives the plain text stand-in for the client secret it's going to hash that value and compare it to the value that it stored before. We're running a little short on time so let me quickly demo this but you'll have the resource list so that you can look at this demo yourself if you're so interested. I'm going to share my screen really quick here and I have a little example here that I call the Pixi CLI and what the Pixi CLI does is it emulates a standalone native client using the Pixi flow and all I have to give it is an Octa org and a client ID. Let's take a look at what's going on here. So the first thing it does is generate the code verifier and it generates the code challenge. That's our plain text value v and our hashed value dollar sign just like we saw in the diagram. It's then going to kick off a connection to our authorization server using an authorized endpoint and what I have highlighted on the screen now this is the standard view or this is the standard authorization code flow but we add two additional parameters which is the code challenge method so that Octa knows the hashing algorithm that we're using and the code challenge which is that hashed value. So now it's going to launch the browser and I'm going to authenticate I'm going to authenticate at Octa this is where I'm supposed to authenticate and now Octa redirects back with an authorization code. Also it's telling me that I can close this tab because the authorization leg of this interaction is now complete and I can see that my little example here got this authorization code which we called alpha just like in the diagram. Now when I press any key to continue it's going to exchange that authorization code using the original code verifier this is our stand in for the client secret and so Octa is going to hash this value and compare it to the code challenge that it stored earlier and now the response that I get back includes an access token and an ID token and it's going to use that access token to hit the user info endpoint and get back a response which proves that this access token was valid. Now in real life you're going to use a library to manage something like the pixie flow but this example does everything close to the metal you can see here that it's building this authorized URL manually and the purpose of that is so that you can you can see what's going on behind the scenes so it's just for demo and you can have access to that at the end. Alright last slide and then we'll address questions again my name is Micah Silverman you can tweet at me at a fit nerd you can tweet at all of Octa's developer advocates at Octa Dev and if you go to developer.octa.com you can get your own free forever Octa org where you can play around with everything that we talked about today including OAuth and OpenID Connect so thank you again for attending I'll pause there and we can start hitting the Q&A alright now let's see I'm looking at the questions list here so bear with me for a second right so first question is what should a spa send for REST we didn't get into great detail so the spa for REST calls is going to send the access token as part of that request that's something that JavaScript can do just fine so it would be a post or a get an endpoint and it would have that authorization header and Octa like many providers has chosen to use JWTs as its access tokens so this gives the API some flexibility in how it validates it one thing the API can do is to validate the the token directly because it's a JWT so it can go and fetch the public key and it can use the algorithm you'd be using some JWT library to validate that the signature is correct and then you could look at the expiration and make sure that it's not expired and then go on from there that's one way if you're dealing with a JWT the other way is what's called the introspect endpoint and this is part of OAuth2 and the API could send that access token whether it's a JWT or not it could send that access token to the introspect endpoint at the authorization server and then the authorization server will send back a response that says either it's valid or it's not alright next we're gonna look I'm just gonna go down the list here we have a bunch of questions and we may not get to all of them I will try to answer all the questions but I understand that at the top of the hour people may need to drop off okay is the OAuth2 password grant type the same as resource owner password credentials flow if yes we're not sending any scope equals open ID in the request to the token endpoint does it fall under OAuth or open ID connect good question alright so there's a couple of questions in that question first of all providing the open ID scope is what distinguishes the interaction from being OAuth or open ID connect so if you don't provide the scope open ID then it's OAuth and you can't get back an ID token you'll only get back an access token now if your response type is explicitly saying that you want to get back an ID token and you don't provide the open ID scope then you'll end up getting an error because it's incompatible open ID tokens only exist in the context of open ID okay octa does have support for the password grant type formally it's the resource owner password grant type and if you're not sending any scope equals open ID then it would just be an old school OAuth interaction and you would just get back the access token now I'm going to assume that that you know the answer makes sense you can send a follow-up question if I didn't properly answer anything just because we have so many people I'm just going to keep going down the list here what's the difference between the data of the ID token and the data of the user info endpoint good question so the ID token is a JWT it's sent back to the application in the authorization code flow when you exchange the authorization code you get back the ID token and typically that would be a light amount of user information and in octa and other providers you can control what gets put into that token typically you wouldn't want a ton of user information in that in that JWT because you start to introduce network latency if it's a really big payload so let's just say for the sake of argument you have a service and part of the user profile includes every movie that I've seen in my entire life well you probably wouldn't want to jam that into the ID token rather when you hit the user info endpoint you can return information back that you wouldn't typically include in the ID token like something that's very verbose like the entire set of movies I've seen in my entire life or also you might use the user info endpoint for more sensitive information that you don't want to come back as part of the ID token all right continuing on how does the API endpoint validate the token submitted with the request as valid we touched on that a bit that is either going to be a JWT validation or an introspect validation that is not a JWT it would have to introspect it has to rely on the authorization server to otherwise it can validate all right we have time for one more question and I apologize it looks like we're not going to get to all of them so let's see what's next is the client secret unique to the Yelp user or unique to Yelp company wide good question so the client secret is issued to the application by the authorization provider so in the context of this question it would be unique to Yelp so Yelp does a registration process with Google Google issues a client ID and a client secret and Yelp stores that in a secure way either as an environment variable or in a database however it does it but that's how Yelp identifies itself to Google both the client ID for the purposes of identifying the application and the client secret the purposes of being able to securely exchange an authorization code for an access token and other types of interactions all right so I've been given the hook by my producers here that was our last question I know there's a bunch of other questions and we'll capture them and consolidate them and see if we can't answer them in follow up I want to thank everybody for joining us today and with that I will release you to the rest of your day have a good one and tweet at me if you have any further questions