 Hey Alexa, are you secure? Let's talk about this. A lot of different developers have the ability to build skills for homes all across the world, millions of them, just like this Echo Dot. Okta gets often asked how do you secure IoT devices, especially with built-in flows like what Amazon provides to developers. So we're going to go through exactly what it takes to secure your skill using Okta and make all of your users a little bit more comfortable with a voice experience. Let's get started. When you log into the Alexa Developer Console, you will land under Alexa Skills Kit on this page. It'll have a listing of all the skills that you've made previously. Let's go ahead and click Create Skill. Now let's create a brand new skill. We're going to name it whatever you'd like. I'll call mine OctaSkill and leave the default language to English. However, if you click the drop-down menu, you'll notice that there are several different language options to choose from and more are being added all the time. Select Custom as the particular type of skill model that we're going to use and provision your own as the option for hosting. Although Alexa hosted apps can be done backed by AWS, because I'm a .NET developer and I enjoy Azure's hosting offering, I'm going to do that on Azure. So we're going to select provision your own and click Create Skill. Once you've done that page, you're going to start from scratch, select Choose. Excellent. Now you will see you're on your basic skill console page. If you look here to the left-hand side, there are a couple of different options that we need to configure. If you notice under Intents, what that means is this is the intended activity that you want the user to do. Think about it as an event. If you notice there are several that you kind of get for free that are already configured by Alexa. So you don't have to put in all the suggested ways that a user might say cancel, help, stop, navigate, et cetera, because it's done it for you. However, we need to have the skill do something. So we're going to first go to invocation and make sure that the way in which our user calls the skill is done properly. So I'm going to go ahead and write it out the way a user would say it. So I'm just going to name it Octa, not Octa Skill, because that is the way in which a user might invoke this skill. Save that model and you'll notice on the right-hand side, this is where all the notification windows are. Now that we've done that, let's click on Intents. Let's add one intent and I'm just going to call it a basic one. Hello intent. I'm going to create that one and give it suggestions of what the user might say. Say hello. Hi. What's up? For example, these are just ways in which you can train the AI behind Alexa. If you look to the right, you see that there's a couple of options. Book edit means exactly that. You can do a comma delimited file of many different kinds of ways that a user might interact with this particular intent and you can also export the listing here as well. We've got everything together. We can just leave this exactly the way it is. Save the model and we're good to go here. Now if we look over here under Endpoint, we're going to select HTTPS because we're going to host this on Azure and this right here under Default Region is where we would put the REST API post endpoint that Alexa can call into our service with in order for us to fulfill the skill's intent. Now we need to create a REST endpoint. Let's do that by going into Windows, Visual Studio, and extending an existing API that we have in place. This particular example is using WebAPI on .NET 4.8. Now you can certainly do this in .NET Core, but this would be the fastest way to get started with an existing API. So let's go to Controllers, right-click, and then add a new controller. Leave this one an empty WebAPI to controller and we're going to call it Octavoice Controller. While it's scaffolding that out for us, I'd like to draw your attention to where you can get the information for the requests and the responses for Alexa. If you go into the Developer Portal underneath your documentation for Custom Interaction Model at the bottom, you'll notice that there's a service interface reference for JSON. There you can go ahead and grab the JSON request and response yourself. Now that's what I've done here because it's just plain old JSON. However, there are several Nougat packages that you could use such as Alexa.NET to make this a little easier for yourself. For me, I just went ahead and added a request and a response model as plain old C-sharp objects here. Now that we have this controller created, let's add a basic call with an anonymous object. This is what that would look like. Since I haven't added the references yet, let's go ahead and take care of that. And as you can see, I'm just doing a basic handling of that request and then inside of that object, which is the name inside of the intent object, I'm creating a handler that just scaffolds that JSON response back to Alexa. So once we go from here, publish that. I already have mine set up already, but let's go ahead and publish this from here anyway. I'm choosing to right click and publish here for this example, but of course you could use an integrated approach through GitHub or whatever repository you have set up. Once that's been published, let's take a look and make sure that it is in place. If you click on API here, you should be able to see the octave voice controller as an option and there it is. Perfect. So let's take the base URL, the name of the controller, and of course the route. Altogether should give us the URL that we're looking to fulfill. Going back to the Alexa developer console here for the default region, go ahead and put that exact URL to that post call and select my development endpoint is a subdomain of a domain that has a wildcard certificate from a certificate authority, like Azure, which is where this has been published. So now that that's put in place, let's save the endpoints. Once that's been saved successfully, let's go ahead and go to the invocation and build the model. You can save things all you want, but without building it, it's not in place with the Alexa ecosystem. So let's add voice to octa on here because it needs to be at least two words for the skill invocation name. Save the model here and build it. It's doing that quick build in progress right now and training the model. Great. Now we're ready to test out what we created. Go back to the Alexa developer console and under endpoint for the default region, put the URL exactly the way that it would need to be put together to reach that post endpoint. And make sure that you select the wildcard certificate option because that is what Azure is in this instance. Click save endpoints. Go to invocation and then build your model. What you're doing here is you're pre-training the Alexa skill to be able to respond to any requests that the user will have. It looks like that full build was successful. So now click on test. The test is currently disabled. So you're going to need to select development in order to type things out in a command driven way. You can say ask, tell, et cetera, but you need to use the invocation name. In this case, it would be octa voice and then the intent, which would be hi, say hello or what's up. So I'm going to type, tell octa voice. Hi. Hello from octa. Now you see a couple of things happen here. The testing browser will of course play sound if you have it enabled and also show you the output and the input that you get. So if you're interested in debugging this, this is a great place to do it. If you scroll down, you'll see the screen representation on an Echo show in this instance as to what you just said to the user. Great. Now you're all set to go. So let's say you've got the basic skill working, but currently any Amazon user can access it. That means that of course you allow anonymous access. This can be really beneficial, especially if you're building a skill where you want it to be an easy conversion rate. But sometimes you're going to want to secure it or at least get more meaningful data ahead of time for your user. So when they log in, you'll know a little bit more about them and ask less questions to secure a skill and know the identity of who is using it. Alexa skills kit offers OAuth 2.0 and through their own proprietary process called account linking, it gates the enabling of the skill or at least part of the functionality. Account linking is what really makes a skill special. The way that we're going to leverage this is to use Okta for managing the login and user data portion of this with a JSON web token using scopes and claims. So why use Okta? Well, all of the OAuth negotiations, if you use Okta, will be configured between Okta and Amazon completely. So you don't have to worry about how the access token is created. You simply use it when it gets to your API, making an otherwise pretty cumbersome process a very easy task. Go to developer.okta.com and sign up for a free account if you do not have one already. Once you have an Okta organization emailed to you, click on the link and log in. It will land you on your dashboard as an administrator. The first thing we're going to do is go to applications, add application and we're going to select web as our authentication. Click next and we're going to name a few things. Let's call it octave voice skill. You can leave your base URL the way that it is and leave the login redirects as they are as well. There's one more thing we're going to need to do here and that is to select refresh token in order for subsequent calls from Alexa to be valid. Click done and now you have the basic application set up in Okta. Down here you're going to see a client ID and client secret. Take note of those and we're going to go back to our skill to enable account linking. Now that we're back in the Alexa developer console, scroll down and notice that there is a link called account linking. Click on that for your skill. The very first thing we want to turn on is allowing users to create an account or link to an existing account. Notice that there's a couple of different types of grants here. The one that we want to use is auth code grant. That is the more secure option of the two. Under authorization URI we'll go over that in a minute but what we're going to need to set up here is our client ID which I copied from the previous and then copy the client secret as well from that Okta application that we created. Under authentication scheme, select credentials and request body. Now there's a couple of things down here at the bottom that I want to draw your attention to. These are the Alexa redirect URLs. We're going to need to copy each one of these and then go back into our Okta voice skill application in Okta. Click edit and add each one of those redirect URLs right here. In order to continue with this I'm going to show you an existing one. If you notice right down here we have not only the login redirect URL set up which was given to us through the account linking screen on our Alexa skill but also an initiate login URI. You're going to save that and come back here. Under scope there's going to be several scopes that we're going to need to add. I'm going to show you an existing Alexa skill that's already filled out for the remainder. This is the Music Guru Alexa skill. Go to account linking and we're going to take a look at how all of this is put together. If you notice I have an authorization URI, an access token URI, client ID and secret which has been obfuscated and I've set up several scopes. Here I have an open ID which is open ID connect, profile which is the name of the user and any other kinds of data you want to preserve for them as well as offline access. Under the domain list this is my particular Okta domain. When you first register for a free one it probably will say something like a dev dash and then some sort of number until you decide to do a custom domain. Down here I've set the default access token expiration time to be a little bit longer so where do we get the authorization URI and access token URI? Glad you asked. Let's go back to our Okta administrative screen. Go to API and then authorization servers. An authorization server allows you to control who can access particular users. I set up one specifically for this existing skill and where you would find the authorization URI and access token URI, the very beginning part of it there you would find underneath API the name of your auth server and the issuer. The issuer is right here. I would copy that and go back here and add v1 authorize if in the case of the authorization URI and then v1 token in the case of the access token. That's all you're going to need there. If we go back here though there's a couple of things we're going to need to add. Under scopes you get several for free but I also added offline access here. This allows an application to access your data when you're not using it in this case it would be Amazon Alexa. Under claims this is the individual pieces of data that you would get back from Okta about your user. Right now we've added first name. I also added an additional claim called favorite band. If you click add claim you can add an additional key value pair of whatever you would like and that would come across as a string. Once you've saved all of that go to your users. Under people you'll see I have a couple of test users here. You can add a person manually or you can enable the registration screen and allow a user to register themselves into your Okta organization once they start the login process. Here I'm going to click on a specific user and take a look at their profile. If you'll notice here down at the bottom I went ahead and created a favorite band entry for them of white stripes. You can always change that here or you can allow the user to change it themselves. Now that we have all of our users set up let's go back into the Alexa developer console. Under scope we're going to need to add open ID profile and offline access here as well as the domain. Once you've done all that click safe. So now that you've set up Alexa and Okta to work with each other in configuration in their portal what do you do in code? Great question. Let's take a look at an existing controller that I extended. Here we've got an anonymous user flow. We've also got one underneath it called an authenticated user flow. We're going to want to use this one to go forward. So if you'll notice inside of the request object I examine the name and look at whether or not it's the hello intent or the favorite band intent which we will go and create in a minute. Inside of the favorite band intent handler this one is going to be an authenticated flow. The hello one doesn't need to know specifically who is accessing it in this example. For the favorite band intent take a look at how little code is needed here. We set a variable to the access token that is provided by Amazon of your Okta token. If it's not null then we decode it using JSON web token security token class and take a look at each of the claims. Remember the claims are a key value pair that you set up in Okta. I take a look at the favorite band and the first name value. Based on those values I then construct a new response that Alexa will say out loud using the user's name and favorite band. Their title and content set to it as well and return the response. If you look at the else statement here you'll notice that if I do not get an access token inside of the user's request object then I will tell the user that they're not linked to the skill and they have to go and link it. Now it's time to put this endpoint to the test. If you go to endpoint here you will notice that I changed this to be an authenticated user although I did leave the wildcard certificate the same. Once I saved that I also created a new intent called favorite band intent and I gave it a couple of sample utterances that a user might say to invoke it. Down here at the bottom you will notice that intent slots are also left empty. The reason that we did this is because we want Okta to be the one to give us the information that is custom to the user and not have the user tell us what that is. However if you wanted to create an intent in which you did get data from the user this is where you would do it. You would create a new slot that says my favorite band is and then allow them to fill out the rest. Once I saved the model and built it we can go back to test enable that and now use the new intent and see if we get anything from Okta. You are not currently linked to this skill. Please go into your Alexa app and sign in. This is exactly what I would expect to find in the test suite inside of the skill itself. In order to really log in a user you're going to have to go to the distribution tab and allow a user to be sent this for beta. Let's go ahead and do that. Click on distribution and fill out all the information below. You're going to need to set up the icons etc but once you've done all this you can save it go to the next page save and continue and now your beta test is active. If you want to add testers you just add them here and then the users will be sent an invitation that they can accept and test from there. Your user should get an email that looks something like this. Once they click enable the Alexa skill then the spot app should pop up. If they click enable then that will allow the user to use the skill in which they could only use the hello intent but we want to do account linking. So if you select settings and then link account this should put your user through the Okta organizations login screen that you've set up. Once the user has successfully signed in through the Okta widget you should be completely linked in that way and then from here you can go ahead and use the request. If you go to your skills dev skills then you'll see the one that was linked right here. Now the user can ask what is your favorite band and it should give the same information that was available inside of the user's profile in Okta. There you have it. Now you've made your Alexa skill just a bit more secure. Comment down below with your questions and we'll either make another blog post or a video just for you. Until next time stay curious.