App registration

Understand the concept

Why it matters

An app registration matters because a small identity setting can take down an entire application without changing application code. A missing redirect URI breaks sign-in. An expired secret breaks background jobs. An overbroad API permission creates audit risk. A wrong supported-account setting can expose an app to tenants it should never serve. A lost owner can delay urgent incident response. In mature Azure environments, app registrations are treated as production assets with owners, credential rotation, permission review, and deployment evidence. They also connect developers and identity administrators: one side needs working authentication, while the other must prevent accidental privilege, consent sprawl, and unmanaged secrets.

Technical context

App registrations live in Microsoft Entra ID and create an application object in a tenant. A related service principal represents that application in a tenant where it is used. The registration controls redirect URIs, supported account types, application ID URI, app roles, API permissions, optional claims, credentials, and federated identity credentials. Azure services, custom APIs, web apps, daemons, and single-page apps depend on these settings for OAuth 2.0 and OpenID Connect flows. It belongs to identity architecture, release governance, and application configuration management.

Exam context

Compare with

Where it is used

Where you see it

1. In Microsoft Entra admin center app registrations, you see client ID, tenant relationship, redirect URIs, certificates, secrets, exposed APIs, app roles, and permissions during reviews.
2. In application settings, pipelines, and Key Vault references, the app registration appears as client ID, tenant ID, authority, secret name, certificate thumbprint, or federated credential.
3. In sign-in logs and token errors, it appears through invalid_client, invalid_redirect_uri, consent-required messages, wrong audience values, expired credentials, and missing service principals.

Common situations

• Register a web application so Microsoft Entra ID can issue tokens only to approved redirect URIs.
• Expose a custom API with scopes or app roles that separate user consent from application permissions.
• Replace long-lived client secrets with certificates or federated credentials for pipelines and workload automation.
• Audit production applications for stale owners, expiring credentials, unused permissions, and risky multi-tenant settings.
• Separate dev, test, and production identity contracts so one environment change cannot break another environment’s sign-in.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

With ten years of Azure engineering experience, I use Azure CLI for app registrations because identity drift is hard to see from portal clicks alone. CLI can list registrations, show client IDs, export redirect URIs, inspect permissions, check credentials, and capture evidence before a release. That repeatability is essential when production, staging, and development apps should differ only in approved ways. CLI is also safer for audit work because reviewers can save exact JSON output instead of screenshots. For changes, I still use review and change control, but CLI makes bulk owner checks, expiring secret reports, permission comparisons, and federated credential validation practical across hundreds of apps.

az ad app list --display-name <app-name> --output table

az ad app show --id <app-id>

az ad app credential list --id <app-id>

az ad app permission list --id <app-id>

az ad app federated-credential list --id <app-id>

Architecture context

Architecturally, an app registration is the identity-plane anchor for an application. It sits outside compute, storage, and network resources, yet every token-based call may depend on it. Web apps need redirect URIs and supported account types. APIs need scopes, app roles, and an application ID URI. Daemons need credentials or workload federation. Multi-tenant software needs explicit consent and publisher discipline. I separate app registration ownership from runtime hosting ownership, document which service principal corresponds to production, and avoid sharing one registration across unrelated workloads. That prevents confusing blast radius when a secret rotates, a permission changes, or one team changes a redirect URI for another team’s production path.

Security

Security impact is direct because an app registration defines who can request tokens, where users are redirected, what credentials exist, and which APIs the app can call. Overbroad delegated or application permissions can expose mail, files, directory data, or custom APIs. Weak client secrets, stale owners, wildcard-like redirect practices, and unreviewed multi-tenant settings increase attack surface. Use least privilege, certificate or federated credentials where appropriate, credential expiration monitoring, admin consent workflows, and separate registrations for environments. Treat client secrets as secrets, not configuration trivia. Review exposed scopes, app roles, reply URLs, and service principal assignments before every production identity change.

Cost

An app registration usually has no direct meter by itself, but it strongly affects operational cost. Unmanaged registrations create support tickets, outage bridges, security reviews, and emergency secret rotations. Sharing one registration across many applications can reduce setup effort but increases coordination cost and blast radius. Overbroad permissions can trigger audit remediation, while missing owners slow incident response. Premium Entra features, governance workflows, identity protection, and external identity scenarios may add licensing considerations around the users and controls involved. FinOps impact is mostly labor and risk: a clean registration inventory reduces wasted engineering hours and prevents expensive identity incidents during critical business windows.

Reliability

Reliability impact is high because authentication failure often looks like an application outage. Expired credentials stop background workers. Removed redirect URIs break user sign-in. Consent changes can block token acquisition for entire customer groups. Misaligned client IDs between slots, environments, or pipeline variables create confusing intermittent failures. Reliable teams document owners, rotate credentials before deadlines, test sign-in flows after changes, and keep separate registrations for production and nonproduction. They also monitor failed sign-ins and token errors, keep rollback manifests, and avoid last-minute portal edits. For critical applications, identity changes should have the same release discipline as code and database changes.

Performance

Runtime performance is indirect, but user-perceived speed can suffer when app registration settings cause authentication retries, consent loops, redirect mismatches, or token cache misses. An app with the wrong authority, redirect URI, or client ID may repeatedly send users through failed sign-in flows before the application ever handles a request. Background jobs can back off or fail when credentials expire. Large identity estates also affect operational performance: without CLI inventory, reviewing owners and credentials across hundreds of registrations is slow and error-prone. Good registration hygiene makes token acquisition predictable, shortens incident triage, and keeps deployment pipelines from waiting on manual identity investigation.

Operations

Operators manage app registrations through ownership reviews, credential rotation, permission audits, manifest exports, redirect URI validation, and incident troubleshooting. Common jobs include finding apps with expiring secrets, listing registrations without owners, comparing required API permissions across environments, confirming service principal existence, and checking federated credentials for GitHub Actions or workload identity. During incidents, operators inspect token audience, issuer, redirect URI, consent state, and credential validity before blaming hosting. Good runbooks include the production client ID, tenant ID, service principal object ID, owner group, change history, rollback manifest, and emergency contact for consent or credential changes. Changes should always reference a ticket, application owner, tested rollback path, and affected environment.

Common mistakes

• Confusing the application object ID, client ID, and service principal object ID during scripts or access reviews.
• Adding production redirect URIs manually in the portal without recording the change in IaC or release notes.
• Leaving expired secrets, abandoned owners, or broad application permissions because nobody owns the registration lifecycle.
• Using one app registration for unrelated workloads and creating a shared blast radius for credential rotation.