foreign to part 18 in this series of creating script addressed apis in servicenow this is the last video in this series on security in the previous video we looked at oauth and how you can use oauth as an extremely secure method for authenticating users using temporary access tokens rather than permanent account credentials another advantage of using oauth is that the oauth specification provides for the use of authentication Scopes authentication Scopes are a way that the client can request limited access to the account without Scopes clients would actually have full access to the account so it's not really about implementing permissions for your API more of restricting access to your API and which the client actually may have more access than what is currently granted by a specific access token that is tied to a specific authentication scope you may have seen Scopes already when using Facebook or Google when you're signing into another application that wants to create photos in your Facebook account or has read access to your photos on your phone so it works in a similar way here from the Tokyo release of service now you can actually Define authentication Scopes as part of using oauth in your instance you can associate a scope to a particular API or a particular method a particular version or a particular resource in a similar way that you could with API access policies which we looked at in the previous video you can then provide these Scopes to or assign these Scopes to the client to the application that you've already registered and that application will then only have the permission to access those parts of the API that are associated with that token because the token is associated with the scope there are a few different use cases for using authentication Scopes one of which may be that your API is just really big and authentication Scopes make for an easier organization of what applications can do what in your API so a very minimum you may consider just creating two Scopes one for read access and one for right access maybe another one for delete access as well and if you happen to be charging for use of your API authentication Scopes may be helpful there as well so let's go ahead and find out how we can create application Scopes assign them to our API or parts of our API assign them to our application as well and see what the result is so let's have a simple use case using two authentication Scopes one for read access to our API and one for deleting records in our table deleting vehicle records so the first thing we'll do is come down to system web services and then rest API auth scope we'll come in here and create a new record we'll give this first one the name Vehicles underscore read and similar to API access policies that we saw in the previous video we can apply this authentication scope to a particular API and then particular parts of that API so on the right hand side here you can see all the check boxes are ticked there which means at the moment it's applying to everything in our API or versions or methods or resources but if we just wanted to restrict this to reading resources or reading vehicles in our table we'll just go ahead and deselect that one here and so that the HTTP method is get so all get methods and we're not restricting it to a particular resource because actually we have two get resources one for a single vehicle and another one for all vehicles so let's just restrict it to get so all read requests coming into our API so the next thing we'll need to do is reference an authentication scope here this authentication scope is just simply a name of the authentication scope so I'll give this the same name just for consistency so we don't get confused we'll put in a brief description here we'll submit that and save the record okay so now we've got our first authentication scope Vehicles read and let's create a second one this time for deleting Vehicles we'll call this Vehicles delete we'll come down to our vehicles API and this time I'm going to select the delete HTTP method okay we'll come over here and create an authentication scope give it a name and provide a description here and submit that okay so two authentication Scopes one for read access one for delete access both applicable to all delete and get methods respectively so the next step is now to come along and assign those authentication Scopes to the application that we created in a previous video so if we come back to system oauth application registry and open up our vehicle scripted rest API which is our mock application that is connecting to the API I probably could have given it a better name it's actually an application it's not an API as such so we need to come down to our related or this list here for authentication Scopes and I'm only going to provide the vehicles read authentication scope here I'm not going to assign the vehicles delete one here and let's see what happens as a result of doing that so I'll save the record so if we come back to postman and to our previous get vehicle version 3 request that was using oauth to authenticate what we can do here I'm just going to get a new access token because when I do that I mean it doesn't matter if it's expired the system a postman will do it already I can request it manually the new token that we get will have the new authentication scope assigned to it already so I don't actually need to specify a scope here explicitly so if I go to get new access token we can see that this new token now has the vehicle's read scope assigned to it that means it is authorized to connect or to make those get requests okay so if we go ahead now close that and send that request that should work just fine and we get that record let's do a second test let's go to our second get request for get vehicles this time okay you can see here that the token is expired again you can manually refresh it but Postman will do that automatically for you when you click on send so I'll refresh it here and then click Send and that should work as well because our authentication scope for reading Vehicles was also assigned well it was assigned to all get requests for all versions actually all right now let's do a third test let's go to delete vehicle will this work what do you think let's try it send no it doesn't work and that's exactly what we expect because that access token was not assigned to the vehicle's delete author authentication scope okay so we don't have access to that resource we get a message here for no vehicle found but we spoke about this in the previous video about error handling and what messages you display to the user depending on what has happened so in our script we could actually do some further work on that to handle the situation where the authentication scope that has been passed with the token is not valid or doesn't match what is necessary for that particular resource okay let's do one more test let's go to create vehicle so for our post methods we haven't defined an authentication scope so let's go ahead and create a new record here or some new records they're going to be duplicates because I created these already in an earlier video and click on send now what do you think will happen will it work or not it works in other words if you do not assign an authentication scope to a resource that means you don't need an authentication scope assigned to your access token you'll have access automatically all right let's do one more test here I'm going to take this Vin here this vehicle identification number here now we weren't able to delete records in version three because we didn't have the necessary authentication scope for our token but let me come back to our version two and go to delete vehicle what do you think will happen now remember our authentication scope is actually assigned to all versions of our API so let's go ahead click on send it worked and that is also by Design as well do you know why think about it all right if we come back to our authentication scope here for delete for vehicles delete we see it applies to the HTTP method to lead for all versions for all resources yet we were still able to delete a vehicle in version two and that is because of the authentication method that is used so if we actually have a look here at the authorization here where you're still using uh basic uh authentication here okay so in other words authentication Scopes only apply to oauth tokens they don't apply when you're using basic Authentication okay so even though we're still able to delete this here it's because of the authentication method so what we could do now is go ahead and now turn off our first two versions of our API so let's do that now let's come back to our scripted rest API record here we can see the default version is number one we've got three versions and all of them are active so let's go ahead and turn off the first two versions and we'll set the version 3 to active or to the default one and save that record so now we've come so far with our API we've iterated through three different versions we've gotten to a point now where our third version of our API is pretty secure we've got access control rules for the API for the resources in the API for the table we're using Glide record secure to enforce those table access control rules we're using oauth to authenticate using temporary access tokens rather than permanent account credentials we're using API access policies to enforce the use of oauth to connect to our API and finally we're using authentication Scopes to further restrict parts of our API based on what token has been assigned to which authentication Scopes so that's it we have now finished developing our scripted rest API for our vehicles table if you've come this far and you've followed along maybe yourself in your own personal development instance of servicenow well done give yourselves a pat on the back because that was a lot of work and interesting work it's a lot of fun developing Integrations but also importantly we have to take care of security as well and as we noted in a previous video there are still occurrences today where data is being breached because apis are not secure enough but hopefully you've seen in the last videos in this series that servicenow offers a plethora of tools built into the platform that are very easy to set up and configure that will really make your API as secure as possible so in the next videos we're going to take a look at testing both in servicenow using the automated tests framework as well as in Postman and then in the penultimate video we will take a look at some reports and statistics that are available for your API connections coming into your instance and then finally we will wrap up the course so thanks for watching this far and we'll see you in the next video foreign