JUMP TO SECTIONChoose a lesson section
Stop treating every identity as a user account.
In identity administration, a correct-looking configuration can still fail because the wrong object, permission type or resource boundary is involved. This guide uses the fictional Northstar Services environment to make those distinctions practical.
App registration ≠ enterprise application ≠ managed identity.
A human user is a directory principal, but so is a service principal. When you register an app in Entra, the application object defines it in its home tenant. A corresponding service principal represents its instance in a tenant. For multitenant software, a customer's tenant can have its own service principal while the publisher retains the application's registration.
Enterprise applications is the Entra administration experience for managing service principals: assignments, sign-in, consent, SSO and provisioning. A managed identity is a special service principal whose credentials are maintained by Azure; it has no ordinary associated app registration object.
App registration
Application object: identifies the app, supported sign-in audience, redirect URIs, credentials or federation and requested permissions.
Where to look: Microsoft Entra ID → App registrationsService principal
Directory security principal representing an application in a particular tenant. The enterprise application entry is the administrative view of this principal.
Where to look: Microsoft Entra ID → Enterprise applicationsManaged identity
A special service principal whose credential management is handled by Azure. Workloads on supported Azure resources can obtain tokens without managing their own secrets.
Where to look: Azure resource → Identity; associated principal in EntraThe application (client) ID identifies an application's definition. Application and service principal objects have distinct object IDs; the service principal in a customer tenant is a separate instance. When debugging, name the ID you're comparing rather than assuming they are interchangeable.
Start with where the code runs—not which portal tab looks familiar.
Identity choices are about lifecycle, trust and security scope. You don't need an employee account for an unattended service, and you shouldn't create a long-lived secret for an Azure-hosted job when a supported managed identity meets its needs.
User identity
An interactive employee signs into a SaaS tool or portal.
User access still needs app assignment, application permissions or local authorization, plus relevant sign-in policies.System-assigned managed identity
One Azure App Service runs an unattended job; the job's identity should disappear when that host is deleted.
Resource lifecycle and role grants remain tied together. A managed identity must be enabled and authorized.User-assigned managed identity
A group of controlled workloads needs a stable identity independent of an individual VM or app host.
Shared blast radius matters: don't reuse the identity across unrelated jobs just because it is convenient.Application service principal
A backend or scheduled task authenticates without a human session using a suitable credential or federated trust.
Prefer workload identity federation where supported; protect and rotate other credentials. Application permissions may grant broad access.Managed service account (where supported)
A domain-dependent service needs a managed AD DS service account, such as a gMSA, rather than an employee password.
AD DS managed service accounts are not Entra managed identities. Their use depends on Windows/service support.Managed identities: system or user assigned?
Lives and dies with one resource.
Enabled directly on a supported Azure resource. That identity is tied to the resource's lifecycle, so deleting the resource deletes the identity. It cannot be shared across resources.
Has its own lifecycle.
Created as a separate Azure resource, attached to one or more supported hosts, and retained even if a host is deleted. Sharing creates a shared access scope that requires deliberate design.
In either model, assigning the managed identity to the source resource does not grant access to every destination. You must authorize the principal on each target, such as an appropriate Azure Storage data role at a suitable scope. Microsoft Entra sign-in and downstream API or resource authorization remain separate checks.
Watch the trust boundary move.
Select a custom application, third-party SaaS app, Azure managed identity or unattended API integration. Follow the identity through its registration or service principal, token request, authorization and evidence trail. Then make four original administrator decisions.
Follow the identity. Prove the permission.
Northstar develops a reporting portal and signs in employees with Entra. One application definition is registered in Northstar's tenant; an enterprise-application service principal represents that app in the same tenant.
- 01App registration
Defines the application in its home tenant: client ID, redirect URIs, sign-in audience and declared permissions.
- 02Enterprise application
The service principal instance: assignment requirements, access, grants, consent and sign-in management in Northstar's tenant.
- 03User authentication
Alex signs in; authentication, Conditional Access and other tenant settings are evaluated.
- 04Resource authorization
The app and downstream API evaluate the token, role/scope grants and local resource permissions.
An app registration is not a user; an enterprise application's service principal is not a separate copy of the application's code.
Look at the application (client) ID to correlate the app registration with its tenant-local service principal; object IDs identify different directory objects.
What would you do at Northstar?
Select a defensible next action for each fictional ticket. Check your choice to see the reasoning. No tenant, credentials or actual systems are involved.
The job runs on one Azure App Service. It needs read-only access to a Storage container. The team wants no credential rotations.
An approved SaaS vendor offers SAML SSO and SCIM provisioning. Only HR should sign in, and deprovisioning needs to be reliable.
An unattended application needs to read approved directory data at night. It asks for application permissions and tenant-wide consent.
The service obtains an Entra token successfully. A read request to a blob is denied with HTTP 403.
A token is not a permission slip for everything.
Microsoft identity integrations can fail despite successful authentication because a caller asks for the wrong audience, requests an ungranted permission, lacks an application role, or is not assigned to the enterprise app. Work backward from the denied operation to the exact authorization layer.
Who or what is calling?
Entra validates the user or workload identity and issues a token when appropriate. The token has an audience and claims.
What may the caller do?
The API, application or Azure resource checks scope/roles, its own policies and actual grants. A valid token alone is insufficient.
Who authorized the requested API permissions?
Authorized users or administrators grant permissions subject to tenant policy. Merely requesting an API permission on an app registration does not grant it.
Which users can open this enterprise app?
Where assignment is required, only approved users/groups receive access. That is different from consenting to the app's downstream API requests.
Does the SaaS system know the user?
SAML/OIDC sign-in and SCIM account provisioning are separate features. A successful Entra login does not guarantee the SaaS account exists or has the right role.
Delegated permissions vs. application permissions
The app acts for a signed-in user.
An interactive user signs in. The application requests delegated scopes, and what it can do depends on granted scopes and the user's own access and API rules. Consent can depend on tenant policy and the scope.
Example: show Alex the files Alex can already access.The app acts as itself.
Background services use application permissions without a signed-in user. Admin consent is normally required; the resulting grant may apply broadly across the organization, subject to resource-specific controls.
Example: an approved overnight job reads a bounded directory dataset.App registration API permissions declare what the app wants. An authorized user/admin still needs to consent according to tenant and permission policy, and the API must honor the resulting grant. Never approve broad application permissions to make a demo work.
Read the access token before changing the permission
Northstar's applications report "authorization failed," but the causes differ. For a token intended for an API, verify the audience (aud), issuer and subject before interpreting privileges. Access tokens are for the receiving API to validate—not a replacement for that API's own authorization logic.
scp: the client has delegated scopes.
A signed-in user calls an API through Northstar's reporting client. The API checks the consented scopes in scp and the user's own authorization to the requested data. The user's app role can also appear in roles.
roles: the app acts without a user.
A daemon uses application permissions. These are represented by app-role grants rather than user-delegated scopes, and require appropriate administrator consent. Do not assume an app-only token has user permissions.
Prove: Service-principal identity, intended API, expected app role and the resource's own authorization. A token by itself is not blanket access.The redirect URI must match the client.
A web client's authorization-code sign-in fails before it gets an access token. Check the registered platform and exact redirect URI, sign-in audience and app configuration before changing API permissions.
Prove: The authentication request's redirect URI matches the registered value. Granting additional Graph permissions cannot fix a redirect mismatch.Requested does not mean granted.
Adding a scope or application permission to the registration does not authorize it in a customer tenant. Inspect the tenant-local service principal and its delegated consent grant or application role assignment.
Prove: Approved permission type, correct consent grant, enterprise-app assignment where required, and an actual successful API request.First identify which service returned the 403 and inspect its access token's audience and permissions without exposing secrets or production tokens in tickets. If those are correct, inspect the API's resource-level authorization. Do not repeatedly grant broader tenant-wide permissions when the failure is at a resource boundary.
SSO gets someone signed in. Provisioning gets them an account.
Northstar adopts a third-party HR application. The publisher already has an Entra integration. Northstar adds an enterprise application, configures supported single sign-on, limits access to HR, and separately configures the vendor's provisioning integration if it supports the organization's lifecycle requirements.
For an employee-facing application, the sign-in experience might use SAML or OpenID Connect. For supported SaaS applications, SCIM provisioning can create, update and deactivate user accounts; it is not automatically enabled just because SSO succeeds. Verify assignment required, application role/group mapping, attribute matching and the SaaS-side permissions.
Decide what you're integrating
Is this your own app, a vendor's gallery SaaS app, an on-premises web app or an Azure-hosted background job? Don't default to creating a new app registration for every SaaS vendor.
Define identity and sign-in audience
For a custom Entra-integrated app, choose a single- or multitenant registration deliberately and configure redirect URIs for the supported app platform. Redirect URI mismatches commonly block sign-in.
Request the narrowest API permissions
Use delegated scopes when a signed-in user is present and the operation acts on that user's behalf; use application roles for truly unattended access when justified.
Approve consent through policy
Review publisher, requested privilege, tenant-wide impact, ownership and expiration. Approval needs a suitable privileged role, not simply the developer's access.
Assign the app and set up SSO
For enterprise apps, verify sign-in protocol, assignment-required behavior, user/group assignment and application roles. Prevent general access where it isn't intended.
Provision, validate and monitor
If supported and needed, configure SaaS provisioning such as SCIM separately. Test with an approved and an unapproved user, review sign-in/provisioning logs, and record ownership and change history.
If the application is an on-premises web app, Entra Application Proxy may provide a supported remote-publishing model, subject to connector, licensing, app-protocol and network prerequisites. That is not the same task as registering an Azure daemon. For large application estates, owners, administrative roles, application collections, monitoring and cleanup also need a lifecycle plan.
Application Administrator and Cloud Application Administrator have different scopes (notably Application Proxy). App ownership can support delegation for a particular app. Review Microsoft's current role descriptions and privilege requirements before assigning consent or management rights.
Four layers can say “Access denied” for different reasons.
When the symptom is vague, distinguish object exists, sign-in succeeds, permission granted and downstream resource allows it. The error source determines where to look first. Log and audit availability can vary by service, license and retention configuration.
The app exists under App registrations but no employee can open it.
First evidence: Determine whether the service principal exists and whether the app exposes a usable sign-in path. Check redirect URI, assignment settings, policy and downstream access.
Avoid: Don't treat app registration as proof a user-facing service is deployed.An OAuth consent prompt requests read/write access for all users.
First evidence: Determine whether the request is delegated or application permission. Check publisher, business purpose, least-privilege alternatives, admin consent policy and approved scopes.
Avoid: Don't grant tenant-wide consent just to dismiss the prompt.The Azure app obtains a token; Blob Storage responds 403.
First evidence: Confirm the intended managed identity, token audience, Storage Blob data role and assignment scope. Azure management roles and data-plane roles differ.
Avoid: Don't disable user MFA or replace the identity before checking authorization.Entra sign-in succeeds, but the SaaS says the user does not exist.
First evidence: Verify whether user provisioning or JIT creation is supported and enabled; inspect SCIM provisioning logs, matching attributes, user assignment and SaaS entitlement.
Avoid: Don't assume SSO automatically creates a user in every SaaS application.A vendor's SAML sign-ins fail after a certificate change.
First evidence: Review SAML metadata, signing certificate validity, identifier/ACS settings and vendor trust configuration. Test with a controlled account.
Avoid: Don't turn off authentication protections to mask an SSO configuration mismatch.Practice 012 contains a three-part Northstar authorization builder. Configure a delegated client, an app-only API worker and an Azure managed identity; then test permitted and deliberately denied operations. Successful token issuance, consent and resource authorization are separate checks.
Open the Application Authorization Builder →This guide builds conceptual and investigative skill in application identities, API permissions and SaaS app access. For hands-on configuration of Application Proxy, app roles, advanced provisioning, and Defender for Cloud Apps, follow the linked Microsoft study guide and current product documentation.
Use the official docs to confirm the configuration details.
Microsoft changes Entra features, role capabilities and licensing. Use these references to validate current behavior, and use JoeLearns to practice the relationships and judgment calls.
Can you authorize the app without over-privileging it?
Keep the existing cards, questions and two tickets, then work three stateful authorization investigations with real modeled allowed and denied outcomes.