 Hi, I'm Heather Downey from Okta. Let's talk about Blazor WebAssembly and how we can integrate it with Okta's easy authentication piece. Let's start with the basics just from the beginning. I'm going to open Visual Studio 2019 and do everything completely from scratch. Start with creating a new project. I'm going to select Blazor app. Click Next. We're going to call this Okta Blazor Watson for WebAssembly. Click Create. We're going to select WebAssembly app. And we're going to have this be a progressive web application. So this way, you could hook it up to your own previously built API. And in the future, we can cover the complete.NET Core hosted application. Click Progressive Web Application. And when it comes to authentication, we're going to select individual user accounts to store user accounts in app. But of course, we're going to replace that with Okta. Click Create. I always go ahead and build the project just to make sure that the templates haven't changed any and there isn't any errors. Looks like everything's working as expected. You'll notice that there's a placeholder here talking about configuring your provider details in program.cs. So that is the very next thing we're going to do. Opening up program.cs, there's a couple of things that we're going to need in here. You'll notice that because we selected individual user accounts during the wizard, local is set up here. But instead, we're going to use Okta for this. So I'm going to comment that out and add an identical line but identifying Okta. Now this is going to pull from the configuration file. The configuration file is going to be under your www root folder. So we're going to expand that and select appsettings.json. You'll notice right now there's a placeholder for just local accounts. But let's go ahead and replace that with what you can find in your Okta user account. Now when you received an email from Okta that gave you the org URL, this is how you would log in as an admin. Great, once you're logged in, click on dashboard and then of course applications. Click add application and because this is Blazor WebAssembly and not traditional.net, we're going to click single page app because we chose for this to be a progressive web app. Let's just call this my Blazor Wassum. Now you'll notice that the base URLs will probably be different than what you have set up in Visual Studio. It's important that you either change Visual Studio to match this local host or you go ahead and go into Visual Studio and get what that is. You can find the URL that is currently set for local host by right clicking on your project, selecting properties, going to debug and you'll see this is the current app URL that is set locally here with just HTTP. But of course you should always be using SSL. So we're going to copy whatever this URL is right here into our clipboard. Now we're going to go back to our Octa app and set the local host to match what we have set up in Visual Studio. Make sure that authorization code is checked. And now we're going to change a little bit of the login and log out redirect your eyes because this is going to be based on the URL that Blazor WebAssembly has built in for login. It will be authentication slash login callback and for logout redirect your eye logout callback. That's all you should need to get started. Just click done. You'll notice at the bottom you'll get your client ID. You will also see that you have no choice but to use Pixi or proof key for code exchange instead of a client secret. So if you're interested more about Pixi, I will definitely link down below. Copy that over and head back to Visual Studio. And now we actually have that client ID, right? So let's go ahead and add that right here. And now we need to change the name of this to Octa like we are setting up in our program dot CS. But the authority still is not correct. So how would you know where to find that? If you go back to your Octa account, you can go to API authorization servers. And you'll see that by default you get a defaults authorization server. Now it's possible that you might have other ones added in here already. But this one just kind of comes for free. If you click on that, you will notice that there is an issuer URL. This is exactly what we're looking for and replaced. You're all set. You should technically be able to get started, right? Not so fast. There's a couple of other lines that we need here. It's important to specify that the kind of flow that we're using is the authentication code flow with OAuth and OIDC or OpenID Connect. The way you do that is by adding the provider option response type directly below it as code. If you're interested in more, bringing over more information in the token than just the user's ID, then you might need to include some other scopes or claims. I'm adding these for examples. We're going into the default scopes and we're just adding profile and address. Well, how do I know where those come from? If you go back to your octoportal and you click on scopes, you'll see that there are some built-in scopes that come out of the box, regardless of whatever kind of configuration you have set up. And a few of those is profile and address, of course. So that means that along with the token, you can specify if you want to include street address, city, state, and like. And other profile information such as their middle name or last. If you go to people under users, you can see an example of this by going to the profile of any user and seeing what attributes are on that profile. This is what it means when that scope is coming. As you can see, there's not a lot on here, but I do have Kansas City here listed. And of course, whenever this is created, it also tracks the time zone. So that'll be something that also will come along with the profile. Now it's time to add some support from our authentication. There are a lot of things that have been done to the getting started templates inside of Visual Studio, specifically around authorization and authentication. The cool thing about this is if you select these templates, you don't have to write a whole bunch of this through scratch, but I'm going to walk you through what it means if you need to use it. There's a couple of ways that you can show an authenticated state in Blazor WebAssembly that's not too far off from what was in Blazor's server side. The built-in authentication dot razor page already handles any actions that come through with a remote authenticator view. If you take a look at app dot razor, you'll find that the entire app, the entire WebAssembly app is wrapped in a cascading authentication state. Within authorized views, you can dictate what you would like to have shown. Now I might change the wording here from authorized to something else, but this will literally cascade through the entire application and you don't have to write a separate one for each page. But if you choose to write something that's individual to the page, you can. Since we already configured program dot CS, let's get rid of this div and change the wording a bit and save that and take a look at what's in the shared folder. If you'll notice there's a couple of things we should pay attention to. One of them is the main layout. In the main layout, there is a reference to a razor component that came for free with the template called login display. Of course this would work with any one that you roll from scratch. This is what the login display looks like out of the box. This just has a simple hello up in the top right-hand corner and there is a toggle between an authorized state and a non-authorized state as to what link you see. It automatically does a login and log out button for the user without any work on your part. If you'll notice the on click event handler is set to a task straight from the sign out manager to set the sign out state and navigate to the log out. This is also built in to Blizzard WebAssembly and is part of the authentication already set up by the framework. There isn't any work that you need to do here or any log out URLs that you need to personally set for Okta. It just works. It's great that all of this works out of the box but I would like to see what claims or what information is inside of my token. Let's go ahead and add a page. Right-click on pages, add a razor page and we're going to call this claims dot razor. Now I'm going to place a snippet of code here and walk you through it. After calling out the page name here we're going to start with an authorized view and within this authorized view we're going to iterate through the identity context of the user with their name and then any claims it brought over. Remember we did request some scopes there but ultimately on the back end inside of Okta you have control over what the token will send and inside of the not authorized state we're not going to let them see the claims. So this is the way you can do it directly on the page level. You can also do it in line anywhere you wish. It could be anywhere on the page but this is a good example of how you can restrict not just by app but by individual page. Looks pretty good to me. Let's see if we can just hit our server. The first time you build it might take a minute. Pay attention to the login at the top right. There isn't really anything on this page or in this site that beckons me to do it. Looking at counter, fetch data, everything works. So we definitely need to add this to the navigation. In order to do that we need to go to the shared folder to the nav menu. Let's just go ahead and add a link to our claims page here called user OIDC claims. Save that and run it again. Anytime you make changes to this it may take a little bit to render. Great. So click around, take a look. There is our message. So now I'm prompted to login. Let's do so. Notice that we're just hitting the login authentication URL if you were to hover over it. And we've been redirected to our identity provider which is Okta. What's cool about this landing page is it's completely customizable and you can change the logo, the look and the feel and that's definitely been referenced in an earlier video that we'll also link below. I have the user already set to go but it's important to note that we have something called self-service registration that also allows the user to sign up directly on the fly or you can use the user management SDK for .NET and set that up yourself to control what that looks like. In the meantime I'm just going to go ahead and use the user that I had set up previously and try to login. I'm instantly redirected back to my .NET app. It's grabbed my name and now I'm actually reflecting that in the front here and if you take a look we can now look at the token claims that were brought along with it. If you notice address is finally here so if I wanted to I could go inside of the address scope and I could look at the locality and I could put that anywhere I want to on the page just by doing aware on the collection of claims. I can also log out and I get that message as well. That's pretty much it. With just a few minutes you've already gotten everything set and ready to go. I was so impressed with the work that the .NET team has done with Blazor WebAssembly specifically making it a lot easier to plug in a third party identity provider like Octa. In the future we'll start taking a look at the different ways that you can use WebAssembly because this particular one we haven't done any token validation yet but we certainly could calling into our own WebAPI in .NET Core or even one built in another language just using Rust call. Hopefully you've learned a little bit about what we can do with Blazor WebAssembly and although there's a lot more that's coming down the line you can see what a game changer this really is. In the future we'll do even more snippets of how to customize user profile and the like. In the meantime, stay curious.