# Azure app registrations: connect the settings to the workload

An app registration provides an identity definition: it tells Microsoft Entra ID which application is requesting authentication, where responses may return, and what API access the application requests. It does not deploy the application or implement its business rules.

Juniper Field Services illustrates three common enterprise needs. Employees sign in to a browser expense application. The client calls an API in their context. An overnight job processes records using its own identity. Each need leads to different configuration choices.

## The two portal views

Use **App registrations** to define the application in its home tenant. Use **Enterprise apps** to operate its service principal in your tenant. Related objects share the application/client ID but have different object IDs. For a vendor's multitenant SaaS application, the vendor owns the definition while your organization controls its local consent and assignments. [Microsoft's object model](https://learn.microsoft.com/en-us/entra/identity-platform/app-objects-and-service-principals)

## Match settings to a flow

A browser SPA uses its SPA callback and modern authorization code flow with PKCE. A confidential server application uses the Web platform and protects its credential on the server. A background client-credentials flow does not need an interactive callback. The public-client fallback switch supports particular flows; it is not a public-website or multitenant switch. [Authorization code flow](https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow), [desktop configuration](https://learn.microsoft.com/en-us/entra/identity-platform/scenario-desktop-app-configuration)

## Treat permission and authorization as separate checkpoints

A requested permission, a tenant's consent grant, the token issued and the API's final authorization are related but distinct. Delegated access operates in a user's context. Application access operates as the workload itself. Limit the scope of the latter deliberately, including supported resource restrictions. [Permissions and consent](https://learn.microsoft.com/en-us/entra/identity-platform/permissions-consent-overview)

Claims carry information; application code gives it meaning. Define a business role, assign the appropriate users or groups and enforce that role in the protected service. Optional access-token claims belong to the resource API's configuration. Changing a client registration will not customize Microsoft's Graph token. [Optional claims](https://learn.microsoft.com/en-us/entra/identity-platform/optional-claims), [app roles](https://learn.microsoft.com/en-us/entra/identity-platform/howto-add-app-roles-in-apps)

## Work through the companion

The versioned download includes a field guide, a design worksheet and an original local MSAL browser lab. The lab displays selected ID-token claims and can request the signed-in user's display name from Graph. Expense rows are fictional local examples. Consult LAB-STATUS-v2.md for the exact executed scope; planned tests are not passed tests.

Record ownership, audience, callbacks, data scope, credentials and both allowed and denied tests before applying the design to production. The goal is a configuration you can explain, test and maintain.

Source baseline: 10 October 2026; recorded access tests: 12 October 2026. The accompanying episode is publicly available on Tunde Automates. No private tenant values are included in the public download.