I've done some reading in regards to Azure AD, but I still can't wrap my head around it. The confusion might be there also because of how my company tries to standarize how a azure project should look like.
Imagine I have two things: SPA app (served by App Service) and API (on this App Service, ASP.NET). The approach that the company is suggesting is that both of those should have their App Registrations.
Now, I'd like the API to have access to Ms Graph. In order to do that, looking at other projects, I updated my AppRegistration to request for Ms Graph roles, Admin gave consent, and in API I used
· It known as safe way to give your web app access to data is to use a
Reference : https://docs.microsoft.com/en-us/graph/auth-v2-service
CodePudding user response:
Let's take a step back and define a few things that will make things easy to understand:
Your app service: this is just a compute environment, just as Azure Functions, Logic apps or VMs. This is where your code executes.
Azure AD App registration: this is an identity that you can use in your code to identify your service and get access to resources you need. The Azure AD app registration has several capabilities:
- build an app in one tenant and used in multiple tenants (multi-tenant app)
- consent framework, allowing you to request permissions and the owner to grant it
- define roles and permissions, so that you can configure who is allowed to call your API
- 3-legged OAuth flows which allows you to act on behalf of the user
- confidential client flows which allow the app to act on its own (like a service account)
Azure Managed Identities: this is also an identity that you can use to identify your service and get access to resources you need. It only has a subset of the capabilities of Azure AD app.
- confidential client flow which allows the identity to act on its own (like a service account)
- credentials managed for you by the platform
Depending on what you are trying to do, you can use one or the other identity: rarely if ever you will need both.
In your case, you need an identity to act on its own. So either app registration or managed identity will work. Your API may benefit from using an app registration if you want to define roles and permissions. The primary advantage of using an app registration in your scenario is that the consent model is simpler to use and understand. The disadvantage is that you need to manage credentials for the app. This pro/con is reversed when using a managed identity.