 So, with that, I will jump into the content here talking about integrating your app into the enterprise. I do have to give you a quick disclaimer, please note the slide on any forward-looking statements that we may be making during the sessions. And also, any names of organizations or companies are all fictitious, so are not intended to represent real companies. So, here we go. I'm Aaron Puraki, Senior Security Architect at Okta. I also work on a lot of the standards OAuth and OpenID Connect and SCIM in those standards groups working with a lot of other people from the industry, and I also do a fair amount of education and training on OAuth and OpenID Connect. For this session, what you can expect, we are going to talk about the difference between how enterprise companies expect to deal with identity problems and how that's different from how consumers expect to deal with identity. We'll talk about how single-sign on works and get into a little bit of the details on OpenID Connect. So, starting with how enterprise companies expect to deal with problems. Now, you are probably familiar with a typical login box with a username and password. This is a very typical way that people start building applications. And this can get you pretty far when you're building a SaaS app, and you may also then quickly realize that you need to support other social identity providers in order to be able to reduce the friction of onboarding or just getting users to come back into your application. So, maybe you've gone and added, you know, Google and Facebook login to your application just to make things a little bit easier for people. Maybe you are actually on the bleeding edge of things, and you've even added support for pass keys into your application to even further reduce the barrier to getting in. What's interesting, though, is that these all have something in common. In all of these cases, the user's account is their own account, and they're all like isolated bubbles from each other. From your app's point of view, you just have a bunch of users. You maybe have them come in through different authentication mechanisms, but it doesn't really matter which one is used at the end of the day. After they're logged in, they're logged in. And again, this can take your SaaS app pretty far as you're growing and scaling your business. You may then realize that what people want is people to have team accounts, and you end up with this one person who wants to use your application with other members of their team, whether that's at a company or a small department within a larger company or just a group of volunteers or a group of friends. So let's say you go and add team support into your application where one user ends up being the team owner and is responsible for adding or removing users to that team. This is again a pretty normal growth story, but as we're quickly growing and adding more and more of these kinds of features, we're getting closer and closer to what it looks like to be a fully enterprise-ready application. Let's say that there's that one user of your app who now loves your app so much that they actually want to get their whole company on it. And it's a thousand person company, so it's definitely something where you're not going to be individually sending up users at that company anymore. In fact, their IT department wants to do a site license and buy the license outright for the whole company rather than maybe your one-off user account pricing that you had done previously. And their IT department says, oh, well, we are not going to let those users log in with their own password to your application. We're not even going to let them have their own Google authenticator, Google account or social login or even pass keys into your application. No, instead, all the users are going to sign in through the enterprise company's SSO provider. So there's no longer any concept of individual user authentication in your application. You need to support the enterprise single sign-on provider for that company. And this is just how they're going to think. This is how they think about things, is the enterprise company has a single sign-on provider that that enterprise users use to log into all of the applications that they use in that company. And there's a lot of benefits to this from the enterprise users, enterprise customers' perspective. There's one place to manage credentials. There's one place to manage multi-factor auth. If they want to require that all employees have multi-factor of a certain type, they can do it in their SSO portal. There's one place to manage who has access to which applications. They probably don't want the salespeople have the same kind of access as the developers. There's developers that need access to different tools. And this is a way for them to assign which users and which groups can access certain applications. And very importantly, it gives them a single place to revoke access, to delete users or revoke access or change and manage which groups of users in in order to shut down access when needed. So basically this means in order for your application that you're building to support enterprise customers like these, you need to support doing a single sign-on flow to their identity provider. So from your perspective, each enterprise customer is going to be a completely different identity provider. And it's kind of like if each enterprise customer was a different social connection like Facebook or Google, where you're going to have to actually build support to integrate to each of your customers enterprise SSO. So the good news is that it's not as complicated because there are open standards for this. There are well-established standards that these SSO providers and identity providers use to integrate with applications. So you can, for the most part, not exactly, but for the most part, write the code once to speak open ID and write the code once to speak SAML and then configure it to different identity providers. In practice, there are little differences between each provider, so you'll have to kind of smooth out those little bumps as you get going. But, broadly speaking, it's these two standards. So what your enterprise users will expect to see is instead of logging into your application with a password, they're going to enter just their email address. And when they enter their email address, your application can discover which identity provider they should be using to log in and send them on their way over there. So instead of your email and password or username and password box, it'll be email. Redirect over to the enterprise identity provider and then redirect back to your application and they're logged in. For example, this is what it looks like when I log into Slack. So I have my Octa employee account. I type in either my Octa email address or I know that Octa's Slack org is octa.slack.com. Click log in. I don't enter a password into Slack. I get redirected over to the Octa account where I use FastPass on the phone. That just gives me a little Face ID flash and then I'm sent back to Slack and I'm logged in and I see all the channels. And again, this is why the enterprise admins like doing this because it gives them these kinds of tools to manage who can access which of these applications that are integrated into the enterprise. So from your perspective, as a SaaS developer, you're going to be seeing the world like this, where you have your app, that's the center of your world, and you're connecting out to a bunch of different identity providers. Some of them might be consumer identity providers like Facebook or Apple. Some might be enterprise identity providers specific to a customer of yours. From the enterprise perspective, they see their identity provider as a center of their universe. And they're going to see that as where they manage everything and how they're able to let applications connect to the enterprise. And they're going to be picking and choosing the best of the SaaS apps that they would like to use and putting them all together under the enterprise IDP. So we're going to go a little deeper now on OpenID Connect to talk about how you can actually do this in your application. For this session, I'm going to focus on the high level of how things work. And in the lab coming up after this session, which will be downstairs, we're going to actually walk you through step-by-step of how to do all of this. So OpenID Connect is actually built on top of the OAuth framework. You might be familiar with OAuth from granting third-party access to accounts like Twitter or Facebook, where they need to get data from some API. OpenID Connect is not about getting access to data, it's about signing in. And it's a slightly different problem, closely related. But the good news is that OpenID Connect is actually, because it's built on top of OAuth, most of the concepts apply to both. There's just one or two new things that OpenID Connect adds into the mix. The main thing that you're going to be dealing with in OpenID Connect is called an ID token. So the ID token is what encodes, it's how the server encodes data about who just logged in and what happened, any attributes about them. And the tricky part about this, which trips up a lot of people, is that ID tokens are defined in the spec as a JSON web token, as a JOT. That is OpenID Connect. OAuth has access tokens. It's always about getting an access token and using that access token to access an API. In OAuth, access tokens might be JSON web tokens, but they definitely don't have to be. And in many, especially many consumer APIs, the access tokens are not JSON web tokens. If you look at an access token from GitHub, it'll just be like a long, random string of characters. So in OAuth, access tokens don't have to be JOTs, but they often are. And there are good reasons to use JOTs as access tokens, especially if your OAuth server is OAuth 0, where it's own separate thing that is not part of your application. Plenty of good reasons for that. We can get into that later if you want. However, even though these two tokens might be JOTs, they are not the same thing, and you cannot mix them up. You can't use them interchangeably. They're for different purposes. I like to think of an OAuth access token as a key. When you get a key and you go open a door, you don't really care what are the little jaggy things on the key mean. You don't need to know that. You just need to know that you can put it in the door and turn the key and the door opens up. More digital version of that would be like a hotel key. You get a hotel key with a magnetic stripe on it, or NFC, and you don't care what's on that key. It doesn't even necessarily say who you are. It just gives you access to something. So again, even though access tokens in OAuth might be JSON web tokens, if you're thinking about this from the applications point of view of using the tokens, don't think about what's in that token. Now, OpenID Connect, on the other hand, this is where you're going to need to get into. That ID token is something you are expected to read when you're building an application that's going to be receiving an ID token. It's kind of like a receipt or like a signed statement where it says, the OAuth server says, this user logged into this application on this date with a password or with MFA and things like that. So these two tokens have different token audiences, which is a specific claim in the jot, but conceptually it just means who is meant to be reading this token. So the audience of the ID token will be the client that got the token. The audience of the access token is going to be the API where you're going to be getting data from. So let's walk through what it will look like to actually start building in an OpenID Connect flow into a SAS app. You're going to take out your password field. You don't need a password field anymore. You're going to put just an email address. They're going to type in an email, and if it matches email domain of a customer, you're going to look up the identity provider for that customer that you've got in your own little database of configuration and send them off to that customer's IDP to log in, which essentially means you're going to have some sort of mapping between email domains and identity providers of your customers. If the email address does not match, then you can fall back to your consumer login flows, like make the password box appear or prompt for a pass key or add the social login options. So let's say they entered a company email address. You did the SSO flow using OpenID Connect. You got back to your app, and now you know who they are because you were able to read the ID token. You're going to then need to have some concept of that user in your own app's database, because you're still going to need to associate records of that user with some record in your database. You're not going to rely on just the random strings you're going to be getting from these IDPs. So you'll put a record in your database, like user ID 1 came from tenant number 1, and their external user ID was this. And then if users from a different company log in, you might have user ID 4 came from tenant ID 2 with this user ID, all in your local database. Now, do you want to just caveat, don't actually use email addresses as a unique identifier for users in any world, whether that's enterprise users or consumer users, because email addresses are not actually a stable identifier, they are a means of communication. And email addresses can change for any number of reasons, like a user changes their name or a company gets acquired. So actually, there is a claim in the ID token called subject, which is a stable unique identifier for that user at that identity provider. And it'll usually be some obscure sequence of characters and numbers that are not significant to you. You just know that it is a stable identifier. So this is probably closer to what your database will actually look like. So the actual flow at a high level is you're building this application, this client, and this flow, it turns out, is going to be the same, whether you're building a mobile app, a single page app, a web server-based app. The sequence of how this works is all the same. You're going to start with the client and have your login button or your email address prompt, and then redirect the browser to the OAuth server, the identity provider. That will send the user's browser over to the authorization server, where they're going to log in there. So that's where the user sees their password prompt. They don't see a password prompt in your app. They see it at the authorization server. Once they log in, it's going to send this authorization code back into the browser, which brings it back to your application. You can then go make a request directly from your client application to the authorization server, exchanging that authorization code for the ID tokens. So the other way to look at this is in this kind of sequence diagram. So imagine that we have the browser on the left. We have the application in the middle, the client application, and the authorization server. So we don't need to go through the details of this. Here, the point is that this whole top chunk of blue lines notice how they always cross through the browser. And that's because these are all redirects back and forth, where it's not like a piece of software making a request. It's just redirecting the browser back and forth from the application to the identity provider and back. The lines at the bottom are the direct post request from your application back to the OAuth server to get the ID token. So when you get the ID token over that back channel, you can parse it out, look at the claims, and figure out who logged in. So what the user sees is a prompt they enter their email address. That'll post back up to your server. Your server checks, do I know this email domain? Is it already an existing user that's gone through some social login? You'll decide what to do with them, like redirect them to their Enterprise Identity Provider. You're not going to see what happens here, which is the entire point. They're going to log in with their own company password, their own multi-factor auth, and all that stuff is just not your problem, which is also really great. And eventually, they get sent back to your application where you can do that code exchange in your login. So the step-by-step of the OpenID Connect flow, if we just look at the URLs and the data moving around, the first thing that happens is your application builds a URL like this to the OAuth server. That's the authorization server's authorization endpoint, and you have all these parameters in the query string that are combination of configuration and runtime information. So client ID is a pre-registered value that you have to get from the OAuth server to start the flow. Redirect URL is where you want the OAuth server to send the user back to. Scope is what part of the user's account you're trying to access. So for OpenID, it's just going to be the OpenID scopes, which are OpenID profile and email, which give you access to the user's email address at that IDP. It gives you access to their name and maybe a username or other profile fields. The code challenge is the extension of OAuth called Pixi, which is a security mechanism to prevent a couple of fun and interesting attacks. So always a good idea. Once the user visits this, this is where they're going to see their login form at their enterprise IDP. Then they're going to do whatever sequence of events their IDP says they need to do to prove who they are. And that server will then create a redirect back to your application. And in that redirect will be this long string called the authorization code, which that's what you can use to get the ID token. So you're going to get this in a redirect, which means you're reading it out of the address bar. So if you're writing a single-page app, you can grab it from the address bar with window.location. If you're writing a server-side application, it'll be one of the query string parameters that your server-side app will receive. You take that. You make a post request back to the OAuth server, exchanging that authorization code for the tokens. And this is the same in OAuth and Obandi Connect, if you're doing the flow this way. The nice thing is that you can actually get both tokens at the same time. If you did need an access token for some reason, which is pretty rare in the enterprise IDP case, but very common in if you're using OAuth for you protecting your own APIs, you can get that access token and the ID token in the same response. And notice that they both start with the same few letters, because they're both JSON web tokens, which is, again, gets back to my earlier point of these look very similar, but don't mix them up. So you grab this ID token from this post request, post response that you just got, and now you're ready to actually figure out what does this mean. Well, a JSON web token is base64 encoder JSON. So you can just base64 decode the ID token, unwrap it, and see what's inside. There's three parts. There's the header, the payload, and the signature. And if you're getting it through the back channel, through this authorization code flow, you can just forget all of that and just grab the middle chunk and parse it out, because you've already done all the checks up until that point anyway. So just grab the middle part with the base64 decoder, run it through a JSON parser, and now you've got the user data. So a couple of interesting things here. Again, subject at the top, that is the unique identifier for that user at the identity provider. It's not a global unique identifier. That would be an impossible task. It is a unique identifier for this user at this identity provider. This identity provider is identified by the claim issuer, ISS, which is that one. And that is the identifier of the OAuth or OpenID server. So that pair is what you can use to be like, oh, is this the same user that I've seen before? So you can associate that issuer with a record in your database if you want to store it that way. And then the rest of these claims are either profile or log in information. So we've got user's name and email are in there. We've got timestamps of when the token was issued, when it expires. AMR is telling me how the user authenticated. So this is actually a really important one. If your application, if you know that your application has requirements that you need all the users to have a second factor, you can actually put that in the request to the OAuth server and they will get prompted for a second factor and then you can confirm it by looking at the AMR claims here. Off time, I think this is an auto-specific one, but that's the timestamp the user last entered a password in case that's relevant to you. And these are the kinds of differences that you might see, depending on the particular OpenID Connect server you're talking to is that sometimes these claims, they add their own custom claims in here. But that's how you can grab the user's info. So this is the high level. We have tons more content on this on YouTube. If you're curious, I've got a bunch of videos on there from myself that go through the details of the step-by-step of how this works in a lot more detail. But today, we are doing the OpenID Connect workshop shortly after this and the lab Enterprise Ready with OpenID Connect. In that lab, we're going to be doing exactly this sequence of events. However, we're not going to need to do much coding at all because it's gonna be done using the Auth0 Enterprise Connections feature. So we'll walk through actually adding an Enterprise Connection in the lab, modifying a very simple to-do list app in order to turn that to-do list app into an Enterprise Ready application that can use Enterprise SSO. So with that, thank you all very much and have a great rest of the day.