Originally, I thought about writing an article about how to get SharePoint list items with Microsoft Graph API by PowerShell. But before doing this, I thought you should first need to know something about app registration in Azure Active Directory in this context. App registrations are really powerful, as you can raise any request if granted.
In this article, I want to illuminate, what is an app registration. For what can it be used and what are the boundaries. After setting a common understanding, I want to share you my considerations about the security of app registrations. At the end of this article, you should be able to understand the impact of app registrations and based on that you will be able to make better decisions, how to use app registrations securely.
Before we start highlighting this topic, let’s answer the following question:
What is an app registration in Azure Active Directory?
An app registration in Azure Active Directory is an authentication and authorization layer to access Microsoft cloud services.
If we want to impersonate or use our scripts as a backend automation e.g., to get SharePoint List items with Microsoft Graph, we need to ensure, that we have set up an app registration in Azure Active Directory. The app registration and the resulting enterprise application provides us the ability to authenticate to Microsoft’s cloud services and also to authorize us for the actions we need to trigger. Means we are not dependent to a functional account like a service user, if we want to run this code as an application, with no human interaction.
- You can configure the app to run in the background – This would be considered as an app with “application permission”.
- On the other hand you can configure app, which impersonate someone – Here you would take “delegated permission”
Considerations about app registration in Azure Active Directory
In this section I want to give you an overview, what to consider in terms of security of app registration in Azure Active Directory
Permissions to create App Registrations
To create an app registration, you need the proper permissions for your user account. By default, every user has the permission to create app registrations in the tenant. If you want to restrict this, you should change this setting below User settings page for your organization (azure.com).
Even if every user is able to create an app registration, they require the requested permission granted by a global administrator for some special permissions. So it is actually not a bad idea to let the users preconfigure their apps.
What permissions can be granted with an app registration in azure active directory?
Before we set up an application registration, we need to think about the security requirements of our organization, and we should answer us the questions accordingly. Since you will be able to have a big impact on the tenant, I suggest you to consult also the security department of your organization to be on the safe side.
- Will this script run in the background e.g., as a Scheduled Task / Runbook in an Azure Automation Account or will this script used by personnel, which can interact with the script and which are granted permission to the content.
- If human interaction is OK, we should design the register the application as delegated permissioned application
- Does any security requirement/ guide/ policy restricts me to use an enterprise application?
- If yes, we should think about an application registration with delegated permissions.
In general, I would strongly encourage you to think about your solution, before you start delegating application permission to your application registration. If any malicious user gets access to the application ID and application secret, he will be able to raise any action in your tenant for the defined set of the permission.
How to create an App Registration?
To create an app registration, you need to browse to Azure Portal:
Register an application – Microsoft Azure
If you encounter this, your administrator has restricted the permission to create apps:
Otherwise, you should see this:
Based on your use case you have the ability to create different supported account types
| Type | Use case |
Accounts in this organizational directory only (Contoso only – Single tenant) | If your app will be used to access resources within your tenant, this is the way to go |
| Accounts in any organizational directory (Any Azure AD directory – Multitenant) | If your app will be used to access resources across your tenant, this is the way to go. This might make sense if your organization is a software provider and wants to grant access to the customer. |
| Accounts in any organizational directory (Any Azure AD directory – Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox) | If your app will be used to access resources across your tenant, this is the way to go. This might make sense if your organization is a software provider and wants to grant access to the customer. In addition you enable users to make use of different identity providers. |
| Personal Microsoft accounts only | If your app is a consumer faced app, this is the way to go. Not suitable for b2b or inter organizational use. |
Further reading:
Authentication and authorization basics – Microsoft Graph | Microsoft Docs
