From the course: Microsoft Graph for Developers

Scenario description

- [Instructor] Next, let's talk about a daemon calling Microsoft Graph. What is a daemon? A server process, a headless process, something that runs on its own and has no user interface, like a cron job, or a Windows service. There is no user identity, and therefore there is no opportunity to log in either. This is actually a pretty valid scenario, especially considering that Azure allows you to run very lightweight functions that can work as a daemon as well. So how can a daemon, where there is no opportunity to log in, how can that process call Microsoft Graph? Well, you treat it just like a web application, as I had explained earlier. Now just with the app key and client ID, just like a web application, you have the ability to authenticate. So one important thing that you may have guessed here is that these applications, even though they're registered as a web application in Azure AD and you can make it multi-tenant, but there is no opportunity to grant consent. It's not like a user is logging in and has to click a button that says Allow this application to run in my tenancy. So the administrator must grant all needed access ahead of time. And yes, you do have refresh tokens that you can use here. In fact, it's almost necessary to have a refresh token in this scenario because where you authenticate and you want to continue working for a very long time like a daemon. So yes, the refresh token is available to us, and yes, you're making a request with an access token, just like every other REST request to Microsoft Graph that we've seen so far.

Contents