What is an App Registration?
App Registrations define applications in Entra ID — their identity, redirect URIs, secrets, certificates, and API permissions. Learn how they work and how to secure them.
What is an App Registration?
Definition
An App Registration in Microsoft Entra ID is the definition of an application: its identity, the OAuth permissions it requests, its redirect URIs, its secrets and certificates, and the tenants in which it can sign in.
When an App Registration is consented to by a tenant, an associated Service Principal (Enterprise Application object) is created in that tenant — the runtime instance of the app with its own role assignments and consented permissions.
In simple terms:
App Registration = the app blueprint. Service Principal = the app instance running in your tenant.
Why App Registrations Matter
- They're how custom apps and SaaS integrations authenticate to Entra ID.
- They hold client secrets and certificates that are credentials in their own right.
- They request API permissions that may grant access to mailboxes, files, directory, and more.
- Misconfigured App Registrations are a top cloud-identity attack path.
Anatomy of an App Registration
- Application (client) ID — unique identifier.
- Object ID — Entra ID directory object ID.
- Tenant — single-tenant or multi-tenant.
- Redirect URIs — where tokens are returned.
- Authentication settings — public client, web, SPA, mobile/desktop.
- API permissions — Microsoft Graph, custom APIs.
- Certificates and secrets — credentials for confidential clients.
- Owners — users who can edit the registration.
- Branding — display name, logo.
- Token configuration — optional claims, app roles.
- Expose an API — define scopes/app roles for the app.
App Registration vs Enterprise Application
| Aspect | App Registration | Enterprise Application |
|---|---|---|
| Object | Application object (in home tenant) | Service Principal (in each tenant) |
| Purpose | Defines the app | Represents the app instance + permissions in a tenant |
| Owners | Manage app definition | Manage runtime: assignments, consent, claims |
| Where seen | "App Registrations" blade | "Enterprise Applications" blade |
You register in one tenant; you can have service principals for that app in every tenant that consents to it.
Permission Types
Delegated Permissions
App acts on behalf of a signed-in user; effective permission = intersection of app + user.
Application Permissions
App acts as itself with no user; full permission of the granted scope. Higher-risk.
Example: Mail.ReadWrite.All as Application permission means read and write every mailbox in the tenant.
Consent
- User consent — user grants delegated permissions for themselves.
- Admin consent — admin grants for the entire tenant.
- Tenant-wide admin consent required for application permissions.
Common App Registration Risks
- Long-lived client secrets (1–2 years).
- Excessive API permissions (Application permissions beyond need).
- Unrotated credentials for years.
- Personal user accounts as owners (offboarded later).
- Multi-tenant apps consented globally without review.
- Wildcard redirect URIs enabling token leakage.
- App Registrations with stale ownership but live high-impact permissions.
- Implicit flow / public clients with too many permissions.
Real-World Examples
1. Storm-0558 Token Forgery
State-aligned attackers obtained an Entra ID signing key and forged tokens to authenticate as users via Microsoft 365 OWA — effectively leveraging the trust placed in Microsoft's own App Registrations.
2. Consent Phishing
Attacker creates a multi-tenant App Registration named "Inbox Cleaner" requesting Mail.ReadWrite and Files.Read.All delegated permissions. Sends phishing link to victims; on consent, the app reads mailboxes persistently.
3. Forgotten App Secret
A legacy app's client secret was stored in source control and never rotated. The repository goes public; attackers extract the secret and call Microsoft Graph as the app for months.
4. Application Admin Backdoor
Application Administrator adds a new credential to a privileged App Registration (e.g., one with Application.ReadWrite.All). The attacker now has app-level Global Admin equivalence.
App Registration Best Practices
Credentials
- Prefer certificates over client secrets for confidential clients.
- Short credential lifetimes (90–180 days max).
- Rotate credentials regularly.
- Monitor credential additions/changes.
- Use Managed Identities for Azure-hosted workloads instead of App Registration secrets.
- Federated identity credentials (workload identity federation) for GitHub Actions, Kubernetes, etc.
Permissions
- Least-privileged scopes. Avoid
*.AllApplication permissions unless required. - Prefer delegated permissions to application permissions.
- Periodic review of granted permissions.
- Disable user consent for high-risk scopes; require admin consent.
- Use admin consent workflow for transparent approval.
Ownership
- Group-based ownership of App Registrations (security groups), not individuals only.
- Review owners quarterly.
- Remove stale owners (offboarded users, role changes).
Configuration
- Strict redirect URIs — no wildcards, exact match preferred.
- Disable implicit flow unless specifically needed.
- Use modern flows: authorization code + PKCE.
Multi-Tenant
- Restrict who can consent to multi-tenant apps.
- Inventory consented multi-tenant apps quarterly.
Detection
- Audit log alerts on credential additions, permission grants, owner changes.
- Use Microsoft Defender for Cloud Apps for OAuth app risk discovery.
App Registration Security Checklist
- Inventory of all App Registrations with owners?
- Credentials short-lived and rotated?
- Certificates preferred over secrets?
- Managed Identities used where possible?
- Application permissions minimized; delegated preferred?
- User consent disabled for high-risk scopes?
- Admin consent workflow enabled?
- Redirect URIs strict, no wildcards?
- Modern OAuth flows (auth code + PKCE)?
- Owner reviews quarterly?
- Multi-tenant apps reviewed?
- Audit log alerts on credential / permission / owner changes?
How Forestall Helps
Forestall maps every App Registration in your tenant:
- Lists credentials, expirations, and rotation history.
- Highlights excessive permissions (especially Application scope).
- Identifies stale or risky ownership.
- Surfaces backdoor potential via Application Administrator role.
- Tracks which App Registrations create paths to privileged data.
Frequently Asked Questions
What's the difference between client secret and certificate?
Both authenticate the app. Certificates are stronger (private key never leaves your control if managed properly) and preferred for production.
Should I use Managed Identity instead?
Yes — for Azure-hosted workloads. Managed Identities eliminate secret management entirely.
What's a multi-tenant app?
An App Registration configured to allow users from any tenant (not just the home tenant) to authenticate.
Are App Registrations and OAuth apps the same?
Largely yes — App Registration is Microsoft's term for the OAuth client/application definition.
Can App Registrations be assigned Entra roles?
Yes — service principals can hold roles. This is common with Microsoft Graph permissions equivalent to admin roles.
Conclusion
App Registrations are how applications gain identity in your Entra ID tenant — and how attackers gain persistence when they're misconfigured. Treat App Registrations as first-class identity objects: minimize permissions, prefer Managed Identities and certificates, govern consent, audit owners, and monitor credential changes. With continuous attention, App Registrations become a powerful integration mechanism rather than a hidden Tier 0 surface.
See every App Registration risk in your tenant.
Forestall inventories App Registrations — credentials, permissions, ownership, and the paths they create to privileged data.