In this video, learn the various scenarios where web apps involving Graph are useful, including REST and CSOM.
This web application has nothing to do with Azure AD really. It may not even be an authenticated web application. It is just calling Microsoft Graph. If you think about, this is actually like a daemon, a headless process, a process that just runs in the background. Now later on the course, I will talk about daemons calling Microsoft Graph but you'll see that Microsoft Graph treats them just like a web application.
Another scenario could be a web application that participates in Office 365 authentication. So the user logs in to the website, and then the website calls Microsoft Graph. In this scenario, when the web application calls Microsoft Graph, there are certain actions that require application-level permissions, and they don't respect or need or sometimes they don't want the user identity in their call.
So that is certainly one scenario where the user logs in to the website, but you're calling Microsoft Graph. Then you're able to get information. Think of it as almost like impersonation. So the call to Microsoft Graph is being made under the application identity, not the user identity. So that's certainly a valid scenario. Where would this be useful? Well, imagine that you write a web application to manage other applications. That would be a pretty good scenario.
But then there could be a scenario where the user logs in to a web application and when a call is made to Microsoft Graph, the identity of the user is sent all the way to Microsoft Graph. Of course, this could also be a very useful scenario. I wish to create a web-based version of Microsoft Outlook that reads my emails or issues a search, and the search results are trimmed based on me, the user logged in.
So the user identity needs to be forwarded on. Now imagine how powerful this can get. I want you to think of one thing at this point, which is that Microsoft Graph is just a web API that Microsoft wrote. So if you used the same concept to write your own web API, which is also just a web application, a number of other scenarios open up for you. For instance, the user can call a web application, which can a web API, which can then call Microsoft Graph.
If you use this architecture, you can share that access token because your access token is good for your web API, which is one resource ID. You can also use this mechanism to call Sharepoint APIs. Sharepoint, CSOM, and REST APIs are not fully migrated to the Graph yet. They are improving every day. But you may run into a scenario where you want to call a classic CSOM API. Using this mechanism, you can forward the user identity all the way to Sharepoint.
And again, why stop at Sharepoint when your identity can now float from API to API to Graph? You know, this is very, very powerful. So you see that this web application calling Microsoft Graph is extremely powerful.
- 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