Workload Identities and Apps

Picture a SaaS app or a script that needs to call Microsoft Graph. In Microsoft Entra ID (formerly Azure AD) that single piece of software is represented by two different objects, and almost every question in this domain turns on keeping them straight. The app registration (the application object) is the global blueprint: registered once in the app's home tenant, it owns the application (client) ID, the redirect URIs, the credentials, the API permissions the app requests, and any app roles it defines. From that one blueprint Entra stamps a service principal in every tenant where the app is actually used, and that local instance is what you see as the enterprise application: where you wire up single sign-on (SSO), assign users and groups, gate access, and apply Conditional Access. The blueprint defines what the app is everywhere; the instance defines what the app may do inside one tenant. The classic trap is reaching for the wrong object: you configure how the app authenticates (secrets, certificates, exposed scopes) on the registration, but you configure how your tenant uses the app (assignment, SSO, consent, provisioning) on the enterprise application. A gallery SaaS app you add has only a service principal in your tenant, because its registration lives with the vendor.

Walk the subtopics in order and the domain reads as one storyline. App Registrations comes first: it is where you define the application object, choose supported account types, and attach the credential the app authenticates with, preferring workload identity federation, then a certificate, and never a client secret in production. Enterprise Applications is the instance side of that same app: you turn on the right SSO mode (favour SAML or OpenID Connect federation), publish on-premises web apps through Microsoft Entra Application Proxy, set whether assignment is required, assign users and app roles, and decide what user and admin consent your tenant allows. Workload Identities zooms in on the non-human credential that actually runs a workload: a managed identity for code on an Azure resource (credential-free, because Azure issues and rotates the certificate), or a service principal from an app registration for a workload outside Azure. Defender for Cloud Apps closes the loop as the governance layer: a cloud access security broker (CASB) that finds shadow IT, controls live SaaS sessions, and reviews the third-party OAuth apps your users have already consented to.

Across the whole domain the exam rewards the choice that removes a stored credential. For a workload, that means a managed identity whenever the code runs on an Azure resource that supports one, because Azure manages and rotates the certificate and nothing can leak; only when the workload runs outside Azure do you fall back to a service principal from an app registration, and even then workload identity federation beats a stored secret. On the registration itself the same instinct orders the credential types: federated credential first, certificate next, client secret only for local development. The mirror-image instinct governs consent and SSO: prefer federation (SAML or OpenID Connect) over password-based SSO, and restrict user consent so apps cannot quietly collect broad permissions, routing risky requests through the admin consent workflow and reviewing standing OAuth grants in Defender for Cloud Apps. Reserve a user account for a human and a group managed service account (gMSA) for on-premises Windows services, never for an Azure resource calling another Azure service.