Application registration subtypes and permissions in Azure Active Directory
This article contains the currently available app registration permissions for custom role definitions in Azure Active Directory (Azure AD).
Permissions for managing single-directory applications
When choosing the permissions for your custom role, you have the option to grant access to manage only single-directory applications. Single-directory applications are available only to users in the Azure AD organization where the application is registered. Single-directory applications are defined as having Supported account types set to "Accounts in this organizational directory only." In the Graph API, single-directory applications have the signInAudience property set to "AzureADMyOrg."
To grant access to manage only single-directory applications, use the permissions below with the subtype applications.myOrganization. For example, microsoft.directory/applications.myOrganization/basic/update.
See the custom roles overview for an explanation of what the general terms subtype, permission, and property set mean. The following information is specific to application registrations.
Create and delete
There are two permissions available for granting the ability to create application registrations, each with different behavior:
Assigning this permission results in the creator being added as the first owner of the created app registration, and the created app registration will count against the creator's 250 created objects quota.
Assigning this permission results in the creator not being added as the first owner of the created app registration, and the created app registration will not count against the creator's 250 created objects quota. Use this permission carefully, because there is nothing preventing the assignee from creating app registrations until the directory-level quota is hit. If both permissions are assigned, this permission takes precedence.
If both permissions are assigned, the /create permission will take precedence. Though the /createAsOwner permission does not automatically add the creator as the first owner, owners can be specified during the creation of the app registration when using Graph APIs or PowerShell cmdlets.
Create permissions grant access to the New registration command.
There are two permissions available for granting the ability to delete app registrations:
Grants the ability to delete app registrations regardless of subtype; that is, both single-tenant and multi-tenant applications.
Grants the ability to delete app registrations restricted to those that are accessible only to accounts in your organization or single-tenant applications (myOrganization subtype).
When assigning a role that contains create permissions, the role assignment must be made at the directory scope. A create permission assigned at a resource scope does not grant the ability to create app registrations.
All member users in the organization can read app registration information by default. However, guest users and application service principals can't. If you plan to assign a role to a guest user or application, you must include the appropriate read permissions.
Ability to read all properties of single-tenant and multi-tenant applications outside of properties that cannot be read in any situation like credentials.
Grants the same permissions as microsoft.directory/applications/allProperties/read, but only for single-tenant applications.
Grants the ability to read owners property on single-tenant and multi-tenant applications. Grants access to all fields on the application registration owners page:
Grants access to read standard application registration properties. This includes properties across application registration pages.
Grants the same permissions as microsoft.directory/applications/standard/read, but for only single-tenant applications.
Ability to update all properties on single-directory and multi-directory applications.
Grants the same permissions as microsoft.directory/applications/allProperties/update, but only for single-tenant applications.
Ability to update the supported account type (signInAudience) property on single-directory and multi-directory applications.
Grants the same permissions as microsoft.directory/applications/audience/update, but only for single-tenant applications.
Ability to update the reply URL, sign-out URL, implicit flow, and publisher domain properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration authentication page except supported account types:
Grants the same permissions as microsoft.directory/applications/authentication/update, but only for single-tenant applications.
Ability to update the name, logo, homepage URL, terms of service URL, and privacy statement URL properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration branding page:
Grants the same permissions as microsoft.directory/applications/basic/update, but only for single-tenant applications.
Ability to update the certificates and client secrets properties on single-tenant and multi-tenant applications. Grants access to all fields on the application registration certificates & secrets page:
Grants the same permissions as microsoft.directory/applications/credentials/update, but only for single-directory applications.
Ability to update the owner property on single-tenant and multi-tenant. Grants access to all fields on the application registration owners page:
Grants the same permissions as microsoft.directory/applications/owners/update, but only for single-tenant applications.
Ability to update the delegated permissions, application permissions, authorized client applications, required permissions, and grant consent properties on single-tenant and multi-tenant applications. Does not grant the ability to perform consent. Grants access to all fields on the application registration API permissions and Expose an API pages:
Grants the same permissions as microsoft.directory/applications/permissions/update, but only for single-tenant applications.
Required license plan
Using this feature requires an Azure AD Premium P1 license. To find the right license for your requirements, see Comparing generally available features of the Free, Basic, and Premium editions.
- Create custom roles using the Azure portal, Azure AD PowerShell, and Graph API
- View the assignments for a custom role