Entra ID App Registrations

An app registration is a representation of your application in Azure AD. It acts as an identity for the application, allowing it to authenticate users and access resources secured by Azure AD. Think of it as a blueprint or template that defines how your application interacts with Azure AD. When you register an app, you provide metadata such as the application name, redirect URIs, supported account types, and permissions it requires. Azure AD then assigns a unique Application (client) ID and, optionally, generates a client secret or certificate for authentication.

Without app registrations, applications would have no way to prove their identity to Azure AD. They enable the OAuth 2.0 and OpenID Connect protocols, which are the foundation for modern authentication. App registrations allow you to:

When you register an app, Azure AD creates two objects: the application object and the service principal object. The application object is the global representation of the app, stored in the tenant where the app is registered. The service principal is the local representation in each tenant where the app is used. For a single-tenant app, there is one service principal in the same tenant. For a multi-tenant app, a service principal is created in each tenant where consent is granted.

The registration process involves: 1. Creating the Application Object: You provide app name, supported account types, redirect URIs, and permissions. Azure AD generates a globally unique Application ID (client_id). 2. Generating Credentials: You can create a client secret (a string) or upload a certificate. Secrets have an expiration date (default 1 year, max 2 years). Certificates provide higher security and can have longer validity. 3. Defining Redirect URIs: These are URLs where Azure AD sends authentication responses. They must be HTTPS (except for localhost in development). For native apps, you can use custom URI schemes. 4. Exposing APIs (optional): If your app provides its own API, you can define scopes and app roles that other applications can request. 5. Setting Permissions: You declare which Microsoft Graph or other API permissions your app needs. These can be delegated (user context) or application-level (app-only).

- Application (client) ID: A GUID that uniquely identifies your app in Azure AD. It is used as the 'client_id' in OAuth 2.0 requests. Example: 12345678-1234-1234-1234-123456789abc. - Directory (tenant) ID: The GUID of the tenant where the app is registered. Used to construct the authority URL: https://login.microsoftonline.com/{tenant-id}. - Client Secret: A string value used by confidential clients to authenticate. Default expiration is 1 year. Can be set to 6 months, 1 year, or 2 years. Secrets are hashed and stored; you cannot retrieve the plaintext after creation. - Certificate: A public/private key pair. The public key is uploaded; the private key is kept by the app. More secure than secrets. Supports SHA256 and SHA384. - Redirect URIs: Up to 256 URIs per app. Must be HTTPS except for http://localhost. For single-page apps, use the auth code flow with PKCE. - Supported Account Types: - Accounts in this organizational directory only (Single tenant): Only users in your tenant can sign in. - Accounts in any organizational directory (Any Azure AD directory - Multitenant): Users from any Azure AD tenant can sign in. - Accounts in any organizational directory and personal Microsoft accounts (e.g., Skype, Xbox): Users with Microsoft personal accounts can also sign in. - Personal Microsoft accounts only: Only for Microsoft accounts, not for work/school. - Permissions: Two types: - Delegated permissions: App acts on behalf of a signed-in user. Requires user consent or admin consent. - Application permissions: App acts as itself (no user context). Requires admin consent. - Pre-authorized applications: You can pre-authorize other apps to access your API without requiring user consent.

Using Azure CLI, you can create and manage app registrations:

# Register an app
az ad app create --display-name "MyApp" --sign-in-audience AzureADMyOrg --identifier-uris "api://myapp"

# Add a redirect URI
az ad app update --id <app-id> --web-redirect-uris "https://myapp.com/callback"

# Create a client secret
az ad app credential reset --id <app-id> --append --display-name "MySecret" --years 1

# List app registrations
az ad app list --query "[].{Name:displayName, AppId:appId}"

Using Microsoft Graph PowerShell:

# Register an app
New-MgApplication -DisplayName "MyApp" -SignInAudience "AzureADMyOrg"

# Add a redirect URI
Update-MgApplication -ApplicationId <app-id> -Web @{RedirectUris = @("https://myapp.com/callback")}

# Create a client secret
Add-MgApplicationPassword -ApplicationId <app-id> -DisplayName "MySecret"

App registrations are the foundation for: - OAuth 2.0 Authorization Code Flow: The app uses its client ID and secret to exchange an authorization code for an access token. - OpenID Connect: Adds an ID token for user authentication. - Microsoft Graph: Apps request delegated or application permissions to call Microsoft Graph APIs (e.g., User.Read, Mail.Send). - Conditional Access: Policies can target applications by their app ID, requiring MFA or location-based access. - Managed Identities: Azure resources (VMs, App Services) can use managed identities instead of app registrations; internally, a service principal is created automatically.

A large enterprise develops an internal HR web app that needs to read employee profiles from Microsoft Graph. The developer registers the app as single-tenant, adds redirect URI https://hrportal.contoso.com/signin-oidc, and configures delegated permissions User.Read.All and Group.Read.All. The admin grants tenant-wide consent so users don't see consent prompts. The app uses the OAuth 2.0 authorization code flow with PKCE. The client secret is stored in Azure Key Vault and rotated every 6 months. Performance is not an issue as the app handles thousands of users. Misconfiguration: If the redirect URI is not HTTPS, Azure AD rejects the authentication request. If permissions are not granted, the app receives HTTP 403 Forbidden when calling Graph.

A SaaS vendor builds a project management tool that customers can sign up for. The app is registered as multi-tenant with supported account types 'Accounts in any organizational directory'. The redirect URI is https://app.projectmanager.com/auth/callback. The app requests delegated permissions User.Read and Tasks.ReadWrite. When a new customer signs in, they are prompted to consent to these permissions. The vendor uses certificates instead of secrets for higher security, rotating certificates annually. The app uses the authorization code flow. Common issue: If the app does not handle incremental consent correctly, users may see unexpected prompts. Also, if the app requests application permissions (which require admin consent), regular users cannot consent and the flow fails.

A background service needs to read all calendar events across the tenant for reporting. The developer registers an app and configures application permissions Calendars.Read. Since application permissions require admin consent, the admin grants consent at the tenant level. The app authenticates using client credentials flow (client ID + certificate). The service principal is created in the tenant. The app runs on an Azure VM with a managed identity, but for external services, a traditional app registration is used. Misconfiguration: If the developer mistakenly uses delegated permissions, the daemon cannot authenticate because there is no user context. Also, if the certificate expires, the service stops working until the certificate is renewed.