In this video, learn to write the JS portion of your AngularJS app.
This is going to do all the heavy lifting of all that WOFF to implicit flow and token management and all of those other things for us. Now this ADAL, angularApp or this module needs to be configured, it needs to be told what resource you are at, we are talking to, and what clientId we are using and we do that with this code. So, we configure our angularApp using ADAL locationProvider, httpProvider, and we basically tell it that these are the endpoints we're interested in.
If you had more than one endpoint, like say you want this application to talk to your custom web API's. This is where you would add that list. I would also like you to look at lines 15 through 21. Over there, I have specified what endpoints I'm interested in, the clientId of my native app, remember this is the native app registration that I did and the tenant in which this application is registered. Right? So, all of that information is specified as configuration information to my module.
Now the next thing I need to do is I need to write that controller. You remember that controller that is supposed to have the login/logout method and a runCommand method. So, that looks like this. The controller couldn't be any simpler. It's basically, we call it angularController to match what we have specified in the front-end and it takes scope, http, and adalAuthenticationService because its adalAuthenticationService, which we have put in a variable called adalService, makes login/logout so easy for us.
In fact, it does more than that. When I execute $http.get, behind the scenes, what it does is that it checks if you're authenticated. If you're not authenticated or let's say, if your session has expired, it'll simply redirect you to the login page. Otherwise, on every get post, call, et cetera, it will put the access token on top. It also puts an invisible Iframe on the page to ensure that the access token is renewed on a timely basis.
So, you see ADAL is doing a lot of these things for us, a lot of heavy lifting that we didn't have to do. Before we run this project, there is one other thing I need to do. Let's go to package.json and in scripts, in start, I will ask it to run lite-server. Now, I wish I could say that I was ready to run this project. Not yet. There is one more thing I need to do. Well, let's go to my Azure AD App Registration and look at the native app and click on all settings and then let's look at required permissions.
The permission that it currently has is User.Read, you see that in the tool tip? Is this permission enough? I don't know because the way to find that out is look at Azure AD Microsoft Graph documentation. So go to the Microsoft Graph documentation site, click on documentation and then a lot of API's that you can call here, but we are calling the user API, so let's go into user and specifically, we are interested in getting the user.
And if you read through this documentation, it says that /me is an alias for me, the currently logged-in user and the permission I need to grant it is User.Read, hey, we already have that permission, right? For the signed-in user I say /me, User.Read is what I need if I was writing, I would need User.Read right? Well there's one more thing you need to do, which is actually grant these permissions to your application. So, this may not be very intuitive, but if you've just registered this application for the very first time or if you have changed permissions, make sure you select the permissions here and then click on this grant permissions part once.
At this point, you are ready to run your application.
- What is Microsoft Graph?
- Registering a web application in Azure AD
- Adding authentication logic and authentication UI
- Native applications calling Graph
- Reviewing scenarios where web apps involving Graph are useful
- Web applications with application identity and delegated identity calling Graph
- Daemons calling Graph