 Hi there, let's talk about authentication and authorization in spas and demystify how they work behind the scenes. We all know that incorporating authentication into our single-page applications is a requirement for most software systems we work on. And luckily, there are some great options out there that make following authentication best practices more straightforward. We want to ensure we're following these best practices so we don't fall victim to attacks. So how do we avoid such attacks? We want to use a reputable identity provider that has authentication and security best practices built in. And it can support us along the way in our development and in production processes. And we want to use a strong proven standard such as OAuth 2.0 and OpenID Connect or IDC. When we talk about OAuth and OIDC, there's a bunch of different flows out there for authentication and it can feel kind of overwhelming. The quick TLDR for spas, which are considered public clients by OAuth definition, is to avoid the implicit flow. This was the previously recommended flow for public clients due to browser limitations. However, browser capabilities have evolved so we can use more secure flows now, which is to use the authorization code flow with the proof key for code exchange extension or PIXI. So let's take a moment to understand how the authorization code flow with PIXI work for public clients by following the sequence of events of the authorization and authentication process. The user wants to sign into their favorite application, a ToDo app. They initiate the authorization code flow by pressing the login button. The client application, that is the ToDo app, kicks things off by creating a code verifier and a code challenge. These are two key pieces of information for the PIXI extension. Now the ToDo app is ready to start communicating with the authorization server, which is octa in this case. The client makes a request to the authorized endpoint so it can get an authorization code. In this request, the client sends data required for authorization, such as which client ID to use, and it sends only the code challenge from the PIXI output, keeping the verifier for a later call. The authorization server redirects the application to a sign-in page they host, allowing for the most amount of security and ease of development of the application developer. The user enters their credentials and any login challenges to grant authorization consent. Success! The authorization server recognizes all is successful and responds with an authorization code, which is a one-time use code, but it keeps track of the code challenge associated with this authorization code. But we're not done yet. We now want to exchange the authorization code for tokens. The client application makes a request to the token endpoint and sends the authorization code along with the code verifier part of the PIXI output. The authorization server validates the request by retrieving the code challenge and comparing it with the code verifier. This ensures that the original requester of the authorization code is the same. With a successful verification, the authorization server returns tokens to the client application. We get back two tokens, an access token used for authorization and an ID token which holds the user identity information. With these two tokens, we're good to go, which means that the user can manage their to-do list. Now that we have a better understanding of the authorization code flow with PIXI and we saw how it works under the covers, let's put it to use in a React app. So what we're going to do is we're going to spin up a React app using the Octa CLI. We could do so by typing in octa start and then we're just going to call it React. What this is going to do is create a Octa application that we'll use for this spa and everything is configured for the spa. So it's going to have the PIXI extension onto it and it's going to use the authorization code flow. And it's also going to create the client ID for us that we'll be using to connect. So let's read CD into the React folder that it creates and it's scaffold out an application for us where we can run NPMCI to install all the dependencies. Let's open this up in WebStorm. So now that it's opened up in WebStorm, we can take a look at some files and see what is going on under the covers. The first one we want to take a look at is this Octa ENV file. This is where the Octa CLI saves some of the metadata that it needs to make the request to the authorization server. It's going to save up the issuer and the client ID here. And then it's going to use these information in this config.js. This is where it creates the configuration information that we need for that authorized call request. We also see here that it's setting that PIXI flag to true so we can get the PIXI extension and where it's also setting the redirect URI, which is how the authorization server knows which URL to redirect the browser back to after the user finishes signing in. And then if we take a look at the app.js file, this is where it's calling the Octa SDK to kick off the authentication process. Let's start the application and see what this looks. So if we hit, if we start npm start, it's going to spin up the application on local host 3000. Now that we have our local application running, we could take a look at this in the browser. So we can navigate to the local host 3000, which is where it's being served. I'm going to go ahead and clear out the network request so that we can watch what this looks like from the very beginning. And notice that I have preserve log enabled so that we'll be able to see all of the calls that is involved in the redirect as well. So when I press login, it's going to redirect me to my authorization server. Now I've customized my authorization server, which is why we see this logo and the background. And it will look a little bit more plain Jane for you. And we can see where it's sending us some of those authorization code request parameters. So if I finish signing in, it redirects me back to the application. And we could see the network calls that it made specifically. We see that it's making a call to that token endpoint. Once it got the authorization code, we take a look at the payload. We see that that code authorization code is there. And in the response, we get back the tokens. We get back the access token, which is used for authorization, and we get the ID token, which is used for authentication and is from the open ID connect layer. Now let's talk about how we would use this in our application. For Upta, the SDK is going to store all of this in local storage. So you can see these tokens. If we take a look at the ID token, this is where we're going to see information about the claims, which is that user identity area. And you'll see name and you'll see preferred username, things like that. Then the access token is just used for authorization for backend server calls. So if we go to our profile, this is where we'll see the ID token and those claims. And this is where you will then be able to start populating the user information. You want to do some verification of the ID token, which the Upta SDKs handles for you. But you want to verify that the issuer is correct, that the nonce is the value that you've passed in, in an original call, and that the token isn't expired. Now that we've taken a look at the ID token and what we get from there and how to verify it, let's take a look at what we do with the access token. So for that, let's go back to that network tab and we're going to click on messages. This is going to call an external resource server that I have running and it is going to add that access token as a authorization header. So we take a look at the request. We see where it's adding the access token there as an authorization header. So it's making an authorized call to your backends. I hope you found this peek out of the covers of how authentication and authorization work for spa is interesting and I encourage you to check it out yourself. Press that like button if you found this video useful and don't forget to click subscribe for more content about identity, authentication, web security and how to use Okta. We also have a developer blog with a post about this very topic covering a lot more details that you might want to check out.