But the endpoint supports , $filter , $select , and $top — which most people underutilize. Useful query patterns # Get an app by its client ID (not GUID id) GET /applications?$filter=appId eq '11111111-2222-3333-4444-555555555555' Get apps with secrets expiring in the next 30 days GET /applications?$expand=passwordCredentials&$filter=passwordCredentials/any(p:p/endDateTime le 2025-05-17T00:00:00Z) Only fetch specific fields (reduces latency) GET /applications?$select=displayName,appId,web,identifierUris 3. Hidden & Undocumented Behaviors api and web are mutually exclusive You cannot have a public client app ( web redirect URIs) that also exposes an API ( api scopes) in the same object—without causing odd validation failures. If you need both, split into two app registrations. signInAudience controls the universe Many developers leave this as "AzureADMyOrg" (single-tenant). But if you ever want to allow personal Microsoft accounts or other Azure AD tenants, change it to AzureADMultipleOrgs or AzureADandPersonalMicrosoftAccount .
But that’s not the same as a ( /servicePrincipals ), which is the instance of that app in a specific tenant.
In Microsoft Graph, an ( /applications ) is the global, multi-tenant definition of an app—its logo, requested permissions, redirect URIs, and certs/secrets.
POST /servicePrincipals
$body = @ displayName = "CI/CD Automation App" signInAudience = "AzureADMyOrg" keyCredentials = @( @ type = "AsymmetricX509Cert" usage = "Verify" key = $base64Cert startDateTime = (Get-Date -Format "yyyy-MM-ddTHH:mm:ssZ") endDateTime = (Get-Date).AddYears(1).ToString("yyyy-MM-ddTHH:mm:ssZ")
GET /applications?$filter=signInAudience eq 'AzureADMultipleOrgs'&$expand=owners($top=1),requiredResourceAccess If the response has an empty owners list, any admin in any tenant could theoretically modify the app's consent permissions. That's a red flag for supply chain risk. The /v1.0/applications endpoint looks simple on the surface—just CRUD on app registrations. But its real power comes from understanding the expansion properties, credential types, and the subtle boundary between application and service principal.
Query for apps with unused delegated permissions: https- graph.microsoft.com v1.0 applications
POST /$batch
Whether you're automating app lifecycle, building an internal governance tool, or hunting for security misconfigurations, this endpoint is your scalpel. Use it with precision, respect its throttling limits, and always—always—validate the signInAudience before you deploy.
"requests": [ "id": "1", "method": "GET", "url": "/applications/id/passwordCredentials" , "id": "2", "method": "GET", "url": "/applications/id/keyCredentials" ] But the endpoint supports , $filter , $select
After creation, you need to create a service principal for that app to appear in "Enterprise applications":
If you're building a production automation that must last years, stick with /v1.0 . For one-off governance scripts or advanced scenarios, /beta is fine. Find all multi-tenant apps (anyone can consent) that have high-privilege permissions and no owner assigned (security risk):
This reduces throttling risk and improves predictability. The /v1.0 endpoint is stable and production-safe. But missing features: If you need both, split into two app registrations
GET /applications?$expand=requiredResourceAccess Then compare with actual API calls. If you expose an API ( api.oauth2PermissionScopes ), the default scope user_impersonation is not automatically added. Many developers forget to define it, then wonder why "Sign in & read user profile" doesn't work. 6. Performance & Throttling Realities This endpoint lives under the /v1.0 workload, which has different throttling than /beta .
$cert = New-SelfSignedCertificate -Subject "CN=Automation" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec KeyExchange -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256 $base64Cert = [System.Convert]::ToBase64String($cert.RawData)