Lesson 14 — App Registrations in Microsoft Entra
Every application that authenticates with Microsoft Entra begins with an app registration.
An app registration creates the application object that defines the application's identity, supported account types, redirect URIs, authentication methods, API permissions, exposed scopes, token claims and credentials.
This lesson explains how app registrations work, how they relate to enterprise applications and service principals, and how Agent Foskett investigates stale credentials, excessive Microsoft Graph permissions and forgotten application identities that have become hidden security risks.
What you will learn
This lesson explains how app registrations define application identity, authentication, permissions and token behaviour inside Microsoft Entra.
Learning objectives
After completing this lesson, you should be able to explain, configure and investigate Microsoft Entra app registrations.
- Describe the purpose of an app registration and application object.
- Explain the relationship between application objects and service principals.
- Configure supported account types, authentication platforms and redirect URIs.
- Compare client secrets, certificates, federated credentials and managed identities.
- Evaluate delegated and application permissions using least privilege.
- Investigate suspicious, excessive or abandoned application registrations.
The problem this solves
Applications need a trusted identity before they can authenticate users, request tokens or call protected APIs.
An app registration defines that identity and tells Microsoft Entra exactly how the application is allowed to authenticate and what resources it may request.
What is an app registration?
An app registration creates an application object in Microsoft Entra. The application object acts as the global definition or blueprint for the application.
The application object
The application object stores the application's client ID, sign-in audience, redirect URIs, credentials, permissions, exposed scopes, app roles and token settings.
It is the configuration blueprint used when the application is represented in one or more tenants.
The service principal
The service principal is the tenant-local security identity created from the application object.
Administrators manage assignment, consent, Conditional Access and sign-in activity through the corresponding enterprise application.
Application object and service principal compared
| Object | Purpose | Typical question |
|---|---|---|
| Application object | Defines how the application is built, authenticated and permitted to request access. | How is this application configured? |
| Service principal | Represents the application as a security identity inside a particular tenant. | What can this application access in this tenant? |
| Enterprise application | Provides the administrative view of the service principal. | Who can use it and which controls apply? |
Supported account types
The sign-in audience determines which users can authenticate to the application.
- Accounts in this organisational directory only.
- Accounts in any organisational directory.
- Organisational accounts and personal Microsoft accounts.
- Personal Microsoft accounts only.
Single-tenant and multi-tenant applications
A single-tenant application is intended for one Microsoft Entra tenant. A multi-tenant application can be consented to by other organisations.
Multi-tenant design increases the importance of publisher verification, consent governance and secure application ownership.
Authentication platforms
| Platform | Typical use | Security focus |
|---|---|---|
| Web | Server-side web applications. | Confidential client credentials, exact redirect URIs and secure session handling. |
| Single-page application | Browser-based JavaScript applications. | Authorization code flow with PKCE and restricted redirect origins. |
| Mobile and desktop | Public client applications installed on user devices. | Public client flows, broker support and device-aware authentication. |
| Daemon or service | Background automation without a signed-in user. | Application permissions and strong workload credentials. |
| Web API | Protected APIs that accept access tokens. | Scopes, app roles, audiences and token validation. |
Redirect URIs
A redirect URI is the location to which Microsoft Entra returns the authentication response after sign-in.
The URI must match the registered value exactly. Unnecessary, wildcard-like or abandoned redirect URIs can create token interception and account takeover opportunities.
Redirect URI review
Review every redirect URI for ownership, HTTPS use, environment, hostname and current business need.
Remove localhost, test, staging and retired domains from production registrations unless they are deliberately required.
Application authentication options
| Method | How it works | Security position |
|---|---|---|
| Client secret | A shared secret proves the application's identity. | Easy to use, but vulnerable to disclosure and poor rotation. |
| Certificate | The application signs an assertion using a private key. | Stronger than a shared secret when keys are protected and rotated. |
| Federated identity credential | Microsoft Entra trusts an external workload identity without a stored secret. | Strong option for supported CI/CD and cloud workloads. |
| Managed identity | Azure manages the workload identity and credential lifecycle. | Preferred for supported Azure resources. |
Client secrets
Client secrets are commonly used because they are simple, but they behave like passwords for applications.
Secrets should have short lifetimes, be stored in a secure vault, never appear in source code and be rotated before expiry.
Certificates and federated credentials
Certificates reduce reliance on shared strings, while federated credentials can remove stored credentials entirely.
Both still require documented ownership, monitoring and a controlled lifecycle.
API permissions
API permissions define which protected resources the application may request access to, including Microsoft Graph and custom APIs.
| Permission type | Identity context | Example risk |
|---|---|---|
| Delegated permission | The application acts on behalf of a signed-in user. | A malicious app may read data available to the user who granted consent. |
| Application permission | The application acts as itself without a signed-in user. | A compromised credential may allow unattended, tenant-wide access. |
Delegated permissions
Delegated permissions are constrained by both the granted scope and the signed-in user's own access.
Examples include reading the user's profile, calendar, files or mail when that access is genuinely required.
Application permissions
Application permissions are designed for background services and automation.
Permissions such as Mail.Read, Files.Read.All and Directory.Read.All can provide broad access and should receive heightened review.
The authentication and token flow
Token configuration
Token configuration controls optional claims and the information included in ID and access tokens.
Only include claims required by the application. Excessive claims can expose unnecessary identity or directory information.
Token types
ID tokens describe the authenticated user, access tokens authorise calls to protected resources, and refresh tokens allow new tokens to be obtained without repeating the full sign-in process.
Expose an API
An application can expose OAuth scopes for delegated access and app roles for application access.
Scopes and roles should use clear names, descriptions and approval boundaries so consuming applications request only what they need.
App roles
App roles support application-specific authorisation and can be assigned to users, groups or service principals.
Role values should remain stable and should map to meaningful business privileges.
Branding and properties
Publisher information, logo, home page, privacy statement and terms of service help users identify the application during consent and sign-in.
Branding improves trust signals, but it does not replace permission review or publisher verification.
The application manifest
The manifest exposes the underlying application-object properties in JSON form.
It is powerful and useful for advanced configuration, but changes should be documented and validated because incorrect values can break authentication or weaken security.
App registration investigation process
Real-world scenario: the client secret never expired
Evidence to review
- Application and object identifiers.
- Creation and modification dates.
- Owners and publisher information.
- Redirect URI inventory.
- Credential names, types and expiry dates.
- Required resource access and consent grants.
- Related enterprise application and service-principal sign-ins.
Immediate containment
- Disable the service principal where appropriate.
- Revoke compromised secrets or certificates.
- Remove unnecessary permission grants.
- Restrict or delete unsafe redirect URIs.
- Review downstream data access.
- Preserve sign-in, audit and consent evidence.
Common mistakes
| Mistake | Why it creates risk | Better practice |
|---|---|---|
| No application owner | Nobody is accountable for permissions, credentials or retirement. | Assign technical and business owners. |
| Long-lived client secrets | Stolen credentials remain useful for an extended period. | Prefer managed identities, federated credentials or short-lived certificates. |
| Excessive Microsoft Graph permissions | The application can access more organisational data than required. | Use least privilege and document every approved permission. |
| Unused redirect URIs | Old endpoints may be taken over or used to intercept responses. | Keep only active, controlled HTTPS redirect URIs. |
| Test and production settings mixed together | Development endpoints and credentials expand the production attack surface. | Separate registrations by environment where appropriate. |
| Forgotten app registrations | Stale credentials and consent grants create hidden access paths. | Review activity and retire unused registrations regularly. |
Key takeaways
- App registrations create application objects that define application identity and authentication configuration.
- Service principals represent those applications inside individual tenants.
- Redirect URIs must be exact, controlled and regularly reviewed.
- Client secrets should be short-lived and securely stored.
- Certificates, federated credentials and managed identities reduce shared-secret risk.
- Delegated permissions act with a user, while application permissions allow unattended access.
- API permissions should follow least privilege and require documented approval.
- Old app registrations, stale credentials and excessive consent grants should be investigated and removed.
Related Agent Foskett resources
Continue learning
Microsoft Entra App Registrations, Application Objects and Credentials
Microsoft Entra app registrations create application objects and define supported account types, redirect URIs, credentials, API permissions, exposed scopes, app roles and token configuration.
Microsoft Entra Academy Lesson 14 — App Registrations in Microsoft Entra
This Agent Foskett lesson explains app registrations, application objects, service principals, redirect URI security, client secrets, certificates, managed identities, Microsoft Graph permissions and application investigations.