Skip to content
iTekConnect

EP 021 / Companion article

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 (opens in a new tab)

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 (opens in a new tab), desktop configuration (opens in a new tab)

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 (opens in a new tab)

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 (opens in a new tab), app roles (opens in a new tab)

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.

Take it with you

Related resources.

Microsoft Entra / ZIP

App registration field guide and MSAL lab

Field guide, identity design worksheet and an original local MSAL browser lab with fictional expense rows.

Test scope: Recorded ordinary-user success, assignment denial, fresh claims, Graph missing-permission denial and redirect mismatch/recovery; no expense API enforcement implemented.

From EP 021: Stop Guessing: How Azure App Registration & Enterprise Apps Actually Work
v2.0 · Updated Oct 12, 2026 · ZIP

Start with a discovery conversation

What could work better?

Discuss a project