In this video, learn what SPA means, and how Microsoft Graph calls work from it.
So just keep that in mind for now. Let's understand the protocol flow as it comes to single-page applications. It all starts with the user navigating to a web application and loading your single page application, and the user can load the application from anywhere, it really doesn't matter. And at this point, the user wishes to be able to make a secure request to a web API, in our case, Microsoft Graph, but you know, it could be really any web API protected by Azure AD.
So a get request with a client ID and a reply URL is sent to the authorization endpoint, so what does that mean? Let's think about that. So when I registered a web application, I received a GUID in return, which was the client ID, or a unique identifier for that web application. Azure AD recognizes my application with that client ID. Well a native application is the same, when I register a native application, I get a client ID in return, but Azure AD is expected to send me back a token.
Where is it going to send it back to? To the reply URL. Now think of it from Azure AD's point of view, Azure AD's going to throw this token into the ether and whoever catches this token will be able to authenticate to the web API. Well we want to make sure that this token is being sent to somebody we recognize, and therefore, when you register this application, you get a client ID, you also at that time need to specify a reply URL, a URL that you trust for this client ID to which the token can be sent to.
And at this point if the user is not signed in to Azure AD, or Office 365 tenancy, the user is prompted to sign in. So this is one of the reasons that this get request sort of needs to be done as a page redirect, because if the user is not signed in, here you have an opportunity to present the user with a sign in dialogue. Assuming that the user signs in properly, at this point, Azure AD authorization endpoint will return the ID token as a URL fragment, it's in the credi string.
What is an ID token? An ID token is a short-lived token, but think of it as a token used to get the access token. So you cannot yet make a call to Microsoft Graph with the ID token, you need to make one more redirect with two components, the ID token and the resource URL of who you wish to call, in our case, Microsoft Graph. So we do another get request, we get a second redirect, and the second redirect contains the ID token, and the resource URL you wish to get an access token for, and an access token is returned to you, and with that access token, you can make a successful rest call to Microsoft Graph or any other web API protected by Azure AD in this manner, and results are sent back to you.
This protocol that I just described to you is also called as OAuth to implicit flow, and it is disabled by default in Azure AD, but enabling it is very easy. We'll check that out momentarily, but a few things become clear here, my application can live on any webpage, as long as it can receive redirects and the reply URL is registered at the right places, it really doesn't matter where my application lives. It could live on an Office 365 page too, absolutely, but this approach is slightly unsuitable for web parts because every web part for every resource you are at is going to perform its own authentication, and therefore, its own to redirect, and therefore, it creates a poor user experience if you have five web parts doing ten redirects on the page.
Also where do you save the access token? Because it's possible that one web part might overwrite another web part's access token if you use local storage for that. Now all of these problems are outside of the purview of this course, but let me say that there are some workarounds to this problem with eight LJS or you can proxy all of these requests to Microsoft Graph, to your own web APS, so you cause one redirect, not 20, but we'll leave that for another day. When I talk about web APS, I feel you'll be able to piece the picture together yourself no problem.
Let's talk a little bit about native apps and multi-tenancy. Native apps are always multi-tenant. You can't make them single-tenant. That makes sense, because imagine if you downloaded an iOS app, and in order for you to use the iOS app against your Office 365 tenancy, we first had to call your administrator and go through a complicated registration process. I think you'd give me a one star on the app store for something like that.
So native apps are always multi-tenant. As soon as the user signs in, the app will prompt the user to register itself. The administrator at the tenancy level can turn this off, but it is on by default.
- 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