Section purpose

This section gives you an administrator-friendly model for understanding modern workload identity in Microsoft Entra. The goal is not to turn you into an OAuth developer. The goal is to help you evaluate application identities, reason about risk, inspect tokens, and choose stronger authentication methods for automation.

Learning Objectives

• Why legacy service accounts remain a major risk pattern
• The difference between app registrations, service principals, enterprise applications, and managed identities
• How secrets, certificates, federated credentials, and managed identities compare
• How to read the key claims in delegated and app-only tokens
• Where permissions, consent, and Conditional Access actually apply

Legacy service accounts: what problem are we solving?

Traditional service accounts were usually ordinary directory identities with passwords. They enabled compatibility, but they also created repeatable weaknesses:

• passwords stored in scripts, config files, and scheduled tasks
• reused credentials across multiple services
• MFA and Conditional Access exceptions to keep automation working
• outages caused by password changes with poor dependency tracking

The cloud version of the same pattern is still risky. A non-human account with a password and a permanent security exception is still a high-value target.

MSA evolution as a bridge to cloud identity

Each generation of managed service account tightened the link between identity and the hosts allowed to use it:

These are not identical to Entra service principals, but they help explain the direction: less password handling and stronger control over how a workload identity is used.

Mapping old concepts to cloud concepts

On-premises patterns have direct Entra counterparts.

Modern Entra workload identities

The minimum model to remember:

• App registration: the application definition
• Application object: the object behind that app definition in the home tenant
• Service principal: the tenant-local instance of the app
• Enterprise application: the admin view over that local service principal
• Managed identity: Azure-managed service principal lifecycle
• Federated credential: a trust relationship that lets an external identity provider (GitHub Actions, Kubernetes, other cloud platforms) exchange its own token for an Entra access token - no stored secret required

One global definition, multiple tenant-local instances.

Federated credentials in detail

Workload identity federation eliminates secrets for external workloads by establishing an OIDC trust between Entra ID and the external identity provider. The flow works like this:

1. The external workload (e.g. a GitHub Actions runner) obtains a token from its own platform IdP.
2. The workload presents that token to the Microsoft identity platform token endpoint.
3. Entra validates the token against the configured federated credential (checking issuer, subject, and audience).
4. If validation passes, Entra issues an access token with no client secret or certificate involved.

Supported external IdP platforms include GitHub Actions, Azure Kubernetes Service, Amazon EKS, Google Cloud, and any platform that publishes OIDC discovery metadata. The trust configuration specifies the issuer URI and a subject identifier that scopes which workloads can authenticate (e.g., a specific GitHub repo and branch).

App registrations, enterprise applications, and IDs

Two views of the same application - different objects, different admin tasks.

App registrations and enterprise applications are not duplicates.

• App registrations is where the app definition lives.
• Enterprise applications is where the local tenant consumes and governs that app.

Important identifiers:

• Application (client) ID: shared across the application object and related service principals
• Application object ID: identifies the application object in the home tenant
• Service principal object ID: identifies the local service principal in a tenant

Good rule:

• same app ID
• different object IDs

Single-tenant versus multitenant

Multitenant apps extend the attack surface across organizational boundaries.

Authentication method ladder

The common operational ranking from weakest to strongest:

Client secret

Certificate

Federated credential

Managed identity

Token basics for administrators

Delegated scenario

Three distinct tokens - each with a different audience and purpose.

The two token models differ in who is acting and what claims appear:

Governance controls

Permissions and consent matter first:

• Delegated permissions shape user-backed app access - the effective permission is the intersection of what the app was granted and what the signed-in user can do
• Application permissions shape app-only access - there is no user ceiling, so the granted permissions are the full blast radius
• Admin consent can approve tenant-wide capability - once granted, every instance of the app can use that permission without per-user consent prompts

Each permission type widens the scope of what the app can reach.

Application management policies

Application management policies let you restrict credential types and lifetimes across all apps or specific apps in the tenant:

• Password credential restrictions - block new client secrets entirely, or cap their maximum lifetime (e.g. 90 days)
• Key credential restrictions - restrict certificate types or require specific trusted CAs
• Scope - policies can target the tenant-wide default or be assigned to specific app registrations

App instance lock

App instance lock can harden sensitive enterprise app instances by preventing changes to specific properties (like redirect URIs and credential configuration) unless the change originates from the app registration in the home tenant. This protects multi-tenant apps where the consuming tenant should not be able to alter the app's security-critical settings.

Conditional Access for workload identities

• User Conditional Access applies to delegated sign-ins through apps - the user's CA policies govern the session
• Workload identity Conditional Access targets service principal sign-ins directly and can enforce location-based restrictions and risk-based blocking
• Service principal sign-in logs support investigation of app-only authentication events

Sign-in logging and investigations

• Service principal sign-ins are visible in Entra logs
• Managed identity sign-ins have their own operational view
• Hourly access token issuance increases log frequency in app-only patterns
• Logs are where admins validate resource, app, result, and IP details

Exchange Online and SharePoint Online nuance

Do not assume every Microsoft 365 workload behaves the same way. Both Exchange Online and SharePoint Online have their own authorization layers on top of Entra identity.

Exchange Online

• Entra identity is only part of the story
• Exchange App RBAC uses Exchange-side authorization constructs
• Exchange-specific scopes and role assignments matter after token issuance
• Legacy Application Access Policies exist, but new design should prefer App RBAC

• An Entra access token gets you to Exchange Online, but the token alone does not determine which mailboxes the app can access
• Exchange App RBAC is the modern model - you create an Exchange service principal, define a management role with specific mailbox scopes, and assign it to the Entra service principal
• The older Application Access Policy approach used New-ApplicationAccessPolicy to restrict which mailboxes an app could access - this still works but Microsoft recommends migrating to App RBAC for new implementations
• The combination of Entra token + Exchange role assignment means you need both layers configured correctly, or the app gets either no access or overly broad access

SharePoint Online

• Preferred modern path is Entra app-only with certificate-based authentication
• Sites.Selected scopes app access to specific SharePoint sites
• Azure ACS app-only was retired on April 2, 2026
• Check Graph docs for latest permissions

• The preferred modern model is Entra app-only with certificate authentication - the app authenticates to Entra with a certificate and receives a token with SharePoint application permissions
• Sites.Selected is the recommended permission scope - check Graph docs for latest permissions, then explicitly grant Read or Write to specific sites via the Graph API or SharePoint admin center
• Azure ACS-based SharePoint app-only was retired on April 2, 2026 - any automation using ACS client IDs and secrets for SharePoint must be migrated to Entra app registrations

9. Current-state deadlines and admin takeaways

Lab readiness notes

Guided lab

Lab goal

Create a single-tenant app registration, inspect the related enterprise application, grant a low-risk Microsoft Graph application permission, request an app-only token, decode the token, and use it to call Microsoft Graph.

Step 0: Sign in and get an admin Microsoft Graph token

Run the REST-based setup steps in the same terminal session so the admin token stays available in $accessToken:

$tenantId = "<tenant-id>"

az login --tenant $tenantId

$accessToken = az account get-access-token --resource-type ms-graph --tenant $tenantId --query accessToken -o tsv

# Can copy this value to jwt.ms to inspect the admin token claims if desired
$accessToken

Entra Portal:

Step 1: Register the app

1. Go to Entra ID -> App registrations.
2. Select New registration.
3. Name the app Session1-GraphReader-<initials>.
4. Set supported account types to Single tenant only.
5. Select Register.

Record:

• Application (client) ID
• Directory (tenant) ID
• Application object ID

Step 2: Open the managed application

1. In the app registration, select Managed application in local directory.
2. Record the enterprise application / service principal object ID.

You should now have:

• one app/client ID
• one application object ID
• one service principal object ID

Step 3: Create a client secret

1. Open Certificates & secrets.
2. Select New client secret.
3. Copy the secret value when it is displayed.

Native PowerShell:

# Replace with your application object ID (NOT the client/app ID)
$appObjectId = "<application-object-id>"
$secretEndDateTime = (Get-Date).ToUniversalTime().AddDays(1).ToString("yyyy-MM-ddTHH:mm:ssZ")

$body = @{
    passwordCredential = @{
        displayName = "Lab secret"
    endDateTime = $secretEndDateTime
    }
} | ConvertTo-Json

$secret = Invoke-RestMethod `
  -Method Post `
  -Uri "https://graph.microsoft.com/v1.0/applications/$appObjectId/addPassword" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body $body

# Save the secret value - it is only shown once
$clientSecret = $secret.secretText
$clientSecret

Graph PowerShell:

Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Replace with your application object ID (same value used in /applications/{id})
$appObjectId = "<application-object-id>"

$secretEndDateTime = (Get-Date).ToUniversalTime().AddDays(1)

$secret = Add-MgApplicationPassword -ApplicationId $appObjectId -PasswordCredential @{
    DisplayName = "Lab secret"
    EndDateTime = $secretEndDateTime
}

# Save the secret value - it is only shown once
$clientSecret = $secret.SecretText
$clientSecret

Az CLI:

# Replace with your application object ID or appId
$appObjectId = "<application-object-id>"
$secretEndDateTime = (Get-Date).ToUniversalTime().AddDays(1).ToString("yyyy-MM-ddTHH:mm:ssZ")

$clientSecret = az ad app credential reset `
  --id $appObjectId `
  --append `
  --display-name "Lab secret" `
  --end-date $secretEndDateTime `
  --query password `
  --output tsv

$clientSecret

Reminder:

• this is the lab convenience path
• it is not the preferred production answer

Step 4: Add Microsoft Graph application permission

Entra Portal:

1. Open API permissions
2. Add Microsoft Graph
3. Choose Application permissions
4. Search and add Organization.Read.All
5. Grant admin consent

Native PowerShell:

# Step 4a: Add Organization.Read.All to required resource access
$appObjectId = "<application-object-id>"

# Microsoft Graph service principal appId is always 00000003-0000-0000-c000-000000000000
# Organization.Read.All role ID: 498476ce-e0fe-48b0-b801-37ba7e2685c6

$body = @{
    requiredResourceAccess = @(
        @{
            resourceAppId = "00000003-0000-0000-c000-000000000000"
            resourceAccess = @(
                @{
                    id   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
                    type = "Role"
                }
            )
        }
    )
} | ConvertTo-Json -Depth 4

Invoke-RestMethod `
  -Method Patch `
  -Uri "https://graph.microsoft.com/v1.0/applications/$appObjectId" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body $body

# Step 4b: Grant admin consent (create appRoleAssignment on the service principal)
$spObjectId = "<service-principal-object-id>"

# Get the Microsoft Graph service principal in your tenant
$graphSp = Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals?`$filter=appId eq '00000003-0000-0000-c000-000000000000'" `
  -Headers @{ Authorization = "Bearer $accessToken" }

$graphSpId = $graphSp.value[0].id

$consentBody = @{
    principalId = $spObjectId
    resourceId  = $graphSpId
    appRoleId   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
} | ConvertTo-Json

Invoke-RestMethod `
  -Method Post `
  -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/$spObjectId/appRoleAssignments" `
  -Headers @{ Authorization = "Bearer $accessToken"; "Content-Type" = "application/json" } `
  -Body $consentBody

Graph PowerShell:

# Step 4a: Add Organization.Read.All to required resource access
$appObjectId = "<application-object-id>"

# Microsoft Graph service principal appId is always 00000003-0000-0000-c000-000000000000
# Organization.Read.All role ID: 498476ce-e0fe-48b0-b801-37ba7e2685c6

Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Replace with your application object ID
$appObjectId = "<application-object-id>"

$params = @{
    requiredResourceAccess = @(
        @{
            resourceAppId = "00000003-0000-0000-c000-000000000000"
            resourceAccess = @(
                @{
                    id   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
                    type = "Role"
                }
            )
        }
    )
}

Update-MgApplication -ApplicationId $appObjectId -BodyParameter $params

# Step 4b: Grant admin consent (create appRoleAssignment on the service principal)
$spObjectId = "<service-principal-object-id>"

Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All"

# Resolve the Microsoft Graph service principal object ID in this tenant
$graphSpId = Get-MgServicePrincipal `
  -Filter "appId eq '00000003-0000-0000-c000-000000000000'" |
  Select-Object -First 1 -ExpandProperty Id

$params = @{
    principalId = $spObjectId
    resourceId  = $graphSpId
    appRoleId   = "498476ce-e0fe-48b0-b801-37ba7e2685c6"
}

New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $spObjectId `
  -BodyParameter $params

Az CLI:

# Step 4a: Add Organization.Read.All to required resource access
$appObjectId = "<application-object-id>"

# Microsoft Graph service principal appId is always 00000003-0000-0000-c000-000000000000
# Organization.Read.All role ID: 498476ce-e0fe-48b0-b801-37ba7e2685c6

az ad app permission add `
  --id $appObjectId `
  --api 00000003-0000-0000-c000-000000000000 `
  --api-permissions 498476ce-e0fe-48b0-b801-37ba7e2685c6=Role

# Step 4b: Grant admin consent for the configured app permissions
# Reuse the application object ID from step 4a.

# This grants admin consent for all permissions currently configured on the app registration.
az ad app permission admin-consent `
  --id $appObjectId

Step 5: Request the token

Native PowerShell:

$tenantId = "<tenant-id>"
$clientId = "<application-client-id>"
$clientSecret = "<client-secret-value>"

$tokenResponse = Invoke-RestMethod `
  -Method Post `
  -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" `
  -ContentType "application/x-www-form-urlencoded" `
  -Body @{
    client_id     = $clientId
    client_secret = $clientSecret
    scope         = "https://graph.microsoft.com/.default"
    grant_type    = "client_credentials"
  }

$accessToken = $tokenResponse.access_token

Graph PowerShell:

$tenantId = "<tenant-id>"
$clientId = "<application-client-id>"
$clientSecret = "<client-secret-value>"

$secureClientSecret = ConvertTo-SecureString $clientSecret -AsPlainText -Force
$clientSecretCredential = New-Object System.Management.Automation.PSCredential($clientId, $secureClientSecret)

Connect-MgGraph `
  -TenantId $tenantId `
  -ClientId $clientId `
  -ClientSecretCredential $clientSecretCredential `
  -NoWelcome

Az CLI:

$tenantId = "<tenant-id>"
$clientId = "<application-client-id>"
$clientSecret = "<client-secret-value>"

az login `
  --service-principal `
  --username $clientId `
  --password $clientSecret `
  --tenant $tenantId

$accessToken = az account get-access-token `
  --resource-type ms-graph `
  --tenant $tenantId `
  --query accessToken `
  --output tsv

$accessToken

Step 6: Decode the token

$tokenParts = $accessToken.Split(".")
$payload = $tokenParts[1].Replace("-", "+").Replace("_", "/")
switch ($payload.Length % 4) {
  2 { $payload += "==" }
  3 { $payload += "=" }
}

$claimsJson = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($payload))
$claims = $claimsJson | ConvertFrom-Json
$claims | Format-List aud, tid, appid, roles, scp, exp

Expected observations:

• appid matches the app registration
• roles includes Organization.Read.All
• scp is empty or missing
• the token expires in about one hour

Step 7: Call Microsoft Graph

$headers = @{ Authorization = "Bearer $accessToken" }
$response = Invoke-RestMethod `
  -Method Get `
  -Uri "https://graph.microsoft.com/v1.0/organization" `
  -Headers $headers

$response

$response.value

Step 8: Review the sign-in evidence

Open service principal sign-ins in the Entra admin center and look for the app-only sign-in to Microsoft Graph.

1. Go to Entra ID → Monitoring & health → Sign-in logs.
2. Switch to the Service principal sign-ins tab.
3. Find the sign-in for your app - look for the application name and a resource of Microsoft Graph.
4. Inspect the details: note the IP address, location, and the authentication method used (client secret).

Quick recap questions

1. Why is a client secret closer to a password than to a managed identity?
2. What is the difference between the application object ID and the service principal object ID?
3. Which claim do you expect in a delegated access token that should not appear in an app-only token?
4. Why does client credentials flow not use refresh tokens?
5. Why should Exchange Online and SharePoint Online be taught as different workload stories?

Key reminders

• Same app ID, different object IDs
• Secrets are the weakest modern option
• App-only access uses application permissions and no user context
• Permissions determine blast radius after authentication
• Sign-in logs remain essential for workload identity investigations
• Monitor Message Center for upcoming authentication changes.

References Appendix

All links below were reviewed on 2026-03-06. Microsoft Learn and Microsoft documentation are the primary sources. Community and MVP posts are included only where they add operational nuance.

Microsoft documentation

• Application and service principal objects in Microsoft Entra ID
• How and why applications are added to Microsoft Entra ID
• Access tokens in the Microsoft identity platform
• ID tokens in the Microsoft identity platform
• Refresh tokens in the Microsoft identity platform
• Microsoft identity platform and OAuth 2.0 client credentials flow
• Developer introduction and guidelines for managed identities for Azure resources
• Securing managed identities in Microsoft Entra ID
• Workload identity federation
• Configure an application to trust a managed identity
• Conditional Access for workload identities
• Service principal sign-in logs
• Learn about the sign-in log activity details
• Understand why a service principal was created in your tenant
• Retirement of service principal-less authentication
• Security best practices for application properties
• Overview of Microsoft Graph permissions
• Microsoft Graph permissions reference
• Get organization - Microsoft Graph v1.0
• Application authentication methods policy resource type
• Secure standalone managed service accounts
• Group Managed Service Accounts overview
• Setting up delegated Managed Service Accounts
• What's new in Windows Server 2025
• Role Based Access Control for Applications in Exchange Online
• New-ServicePrincipal (Exchange Online PowerShell)
• App-only authentication (Exchange Online PowerShell)
• Granting access via Entra ID Application Permissions
• Retirement announcement for Azure ACS in SharePoint Online

Community and MVP references

• Tony Redmond: Entra ID to Disable Service Principal-Less Authentication
• Vasil Michev: ExO RBAC improvements #1: Limiting application access
• Vasil Michev: More on service principal permissions in Exchange Online