1. Application Objects & Service Principals

In Entra ID, an application identity is split into two parts:

  • App Registration (The Blueprint): Created in the app’s home tenant, this global setup defines the app’s identity, redirect URIs, required API permissions, and credentials.
  • Enterprise Application (The Service Principal): The local instance running in a specific tenant. Admins use this local copy to grant consent, assign roles, enforce Conditional Access, and control user access.

2. Non-Human Identities: Service Principals vs. Managed Identities

  • Service Principals (Standard Application Identity):
    • Created automatically when an App Registration is registered or approved in a tenant.
    • Used for custom code, multi-tenant SaaS, cross-tenant connections, or background services.
    • Requires manual tracking and rotation of credentials (secrets, certificates, or federated tokens).
  • Managed Identities (Azure-Managed Service Principals):
    • Dedicated identities automatically created and managed by Azure for supported resources (e.g., VMs, App Services).
    • Eliminates password management: Entra ID automatically handles creation, rotation, and secret storage behind the scenes.
    • Functions purely as a local Service Principal without needing a separate App Registration.

3. Power Platform & Managed Identity Scopes

Managed Identity support in Power Platform is component-specific rather than environment-wide.

  • Environment Level (Not Supported): Environments do not have a single native Managed Identity. Standard out-of-the-box connectors (e.g., Power Automate, Canvas Apps) must use standard Service Principals or user connections.
  • Component Level (Supported): Managed Identities are natively supported at the Dataverse Plug-in assembly level. Signed code packages bind to a User-Assigned Managed Identity via Federated Identity Credentials.
  • Architecture Workarounds: For flows or apps needing keyless access, route requests through a Dataverse Custom API/Plug-in bound to a Managed Identity, or offload execution to Azure Functions / API Management running a managed identity.

4. Permission Scopes: Delegated vs. Application

  • Delegated Permissions (User Present):
    • Used when an app acts on behalf of a signed-in user.
    • The app’s actual access is limited by what the signed-in user is allowed to do.
    • An app cannot perform any action that the user lacks rights for, even if the permission is consented.
  • Application Permissions (App-Only / Background Services):
    • Used by background processes, automation scripts, or daemons without user interaction.
    • Grants full tenant-wide access for the approved scope (e.g., Directory.ReadWrite.All).
    • Requires Admin Consent and poses significant risk if credentials leak.

5. Authentication Credential Types: Lifespans & Rotation

  • Client Secrets (Symmetric Keys):
    • Validity: Capped at 2 years (730 days) when created in the portal.
    • Rotation: Manual or scripted. Requires overlapping two secrets temporarily to avoid service downtime before removing the old one. High security risk if leaked.
  • Certificates (Asymmetric Keys):
    • Validity: Configurable (typically 1 to 3 years; 1 year recommended).
    • Rotation: Upload an updated public certificate (.cer) to the App Registration while storing the private key (.pfx) in Azure Key Vault. Apps pull the active key from Key Vault dynamically.
  • Federated Identity Credentials (FIC / Workload Identity Federation):
    • Validity: Secretless. Short-lived tokens exchanged with Entra ID usually last 1 hour. The trust configuration does not expire unless removed.
    • Rotation: Fully automated. Entra ID verifies incoming tokens against external systems dynamically. Eliminates long-lived secrets entirely.

6. The Basics of how OIDC Works for Federated Credentials

Instead of storing a static password, Workload Identity Federation uses OpenID Connect (OIDC) to exchange external proof of identity for an Entra ID token.

  • 1. Token Request: Your app or pipeline (e.g., GitHub Actions, Kubernetes) requests a short-lived JSON Web Token (JWT) from its own platform’s token service.
  • 2. Token Presentation: The app sends this external JWT to Entra ID’s token endpoint instead of a client secret or certificate.
  • 3. Issuer Discovery: Entra ID inspects the iss (issuer) claim in the incoming JWT. It contacts the issuer’s discovery endpoint (https://<issuer>/.well-known/openid-configuration) to retrieve metadata, specifically locating the jwks_uri (JSON Web Key Set URL).
  • 4. Signature Verification: Entra ID fetches the issuer’s public signing keys from the jwks_uri and uses them to cryptographically verify that the token was signed by the real external provider and hasn’t been tampered with.
  • 5. Claims & Trust Validation: Entra ID checks the token’s internal fields against the rules configured on your Federated Identity Credential:
    • Issuer (iss): Matches the trusted external provider URL.
    • Audience (aud): Matches expected target (usually api://AzureADTokenExchange).
    • Subject (sub): Matches the specific repository, environment, branch, or service account authorized to connect.
  • 6. Token Exchange: Once verified, Entra ID exchanges the external token for a native Entra ID access token, allowing your workload to access Azure resources without ever using a long-lived password.

7. Essential PowerShell Cmdlets (Microsoft Graph)

  • Connection & Administrative Scopes:
    • Connect-MgGraph -Scopes "Application.ReadWrite.All", "DelegatedPermissionGrant.ReadWrite.All"
  • App Registrations & Service Principals:
    • Get-MgApplication -Filter "displayName eq 'MyApp'" (Find App Registration blueprint details)
    • Get-MgServicePrincipal -Filter "displayName eq 'MyApp'" (Find local Enterprise Application Service Principal)
    • New-MgApplication -DisplayName "New-Daemon-App" -SignInAudience "AzureADMyOrg" (Provision a new App Registration)
    • New-MgServicePrincipal -AppId <AppID> (Instantiate an Enterprise App Service Principal from an App Registration)
  • Credential & Federated Identity Management:
    • Add-MgApplicationPassword -ApplicationId <AppObjId> -PasswordCredential @{displayName="Secret-2026"} (Add client secret)
    • Get-MgApplicationFederatedIdentityCredential -ApplicationId <AppObjId> (View configured Federated Credentials)
    • New-MgApplicationFederatedIdentityCredential -ApplicationId <AppObjId> -Name "GitHub-Actions-Prod" -Issuer "https://token.actions.githubusercontent.com" -Subject "repo:org/repo:environment:prod" -Audiences "api://AzureADTokenExchange" (Set up Workload Identity Federation)
  • Managing Consented Scopes & Permissions:
    • Get-MgApplicationKeyCredential -ApplicationId <AppObjId> (Check certificate expiry dates and public keys)
    • Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId <SPObjId> (List active delegated permission grants)