In this video, learn the token and request flow behind web app calling Microsoft Graph with app identity.
- There are a number of scenarios where web applications calling Microsoft graph is useful. But let's start by learning, web application calling graph with just the application identity. Application identity only. So here, the web API in the back-end in this case, Microsoft graph, does not receive the user identity. It still gets the application identity, and the application identity must have the proper rights to work that it is trying to run.
So it is secure, and you'd need to grant the appropriate permissions. And since this is all protected by Azure AD, the user still needs to log in, but the identity is not forwarded to Microsoft graph. How does this work? Well step one, is the user logging in. And this is something that you have already seen, in the second module of this course where I talked about a web application protected by Microsoft graph.
In fact, when we write code for this scenario, for web application calling Microsoft graph for the application identity. I will actually start with the code that we ended with, in the web application protected by Azure AD. But once you have signed in, there is one key difference, that you're going to get an APP secret, and with that secret you get an ID token.
And now what happens when you wish to make a call to the web API? The web application requests for an access token. And it does so, by providing the auth code and the client ID for the web app, a secret, which is the credential or the secret becomes part of the credential, and a redirect URI and a APP ID URI. So with that information, the Azure AD token endpoint will return you an access token and a refresh token.
So yes, there is a refresh token in play there. Remember that the user is still signed into this web application. So this refresh token, is being shared for every single user signed into this web application. Now with this access token, you can call the web API and you can get the resource back. And again, as usual when the access token expires, ADAL will help us, using the refresh token to get a new access token.
So again token management here, ADAL manages it all for us and access tokens can be refreshed in this case using refresh tokens. But the important thing to remember here, is that since we are using application identity, in others words, the same identity is being forwarded to Microsoft graph no matter how many users sign into the web application. We don't need to keep the access token and refresh token separate for every user. So this sort of simplifies things for us.
Because ADAL out of the box will manage tokens for us and it does so, by managing them in memory. So we don't need to write our special token cache in this scenario.
- 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