App Registrations: Build & Secure

What are app registrations?

App registration vs enterprise application

This is one of the most tested concepts in SC-300:

Aspect	App Registration	Enterprise Application (Service Principal)
What it is	The global identity definition (blueprint)	The local instance in a specific tenant
Where to find it	Entra admin center → App registrations	Entra admin center → Enterprise applications
Who manages it	The developer / app owner	The tenant admin
Contains	Client ID, redirect URIs, API permissions, credentials, app roles	User assignments, SSO config, provisioning, consent grants
Analogy	A franchise brand (McDonald’s corporate)	A specific franchise location (McDonald’s on Queen St)

💡 Exam tip: Registration creates the principal

When you create an app registration in your tenant, a service principal is automatically created in the same tenant. When a user in another tenant consents to your multi-tenant app, a service principal is automatically created in their tenant. One registration → many principals.

Planning app registrations

Before creating a registration, plan these decisions:

Decision	Options	Guidance
Single-tenant or multi-tenant?	Single: only your tenant. Multi: any Entra ID tenant.	Use single-tenant unless external tenants need access
Account types	This org only, any org, any org + personal Microsoft accounts	Match your audience — internal LOB app = this org only
Platform type	Web, SPA, mobile/desktop, daemon/service	Determines which authentication flow is appropriate
Redirect URI	Where Entra ID sends tokens after authentication	Must be HTTPS (except localhost for dev). Exact match required.
Credentials	Client secret or certificate	Certificates are more secure — recommended for production

Creating an app registration

Steps:

1. Entra admin center → App registrations → New registration
2. Enter a display name (e.g., “Patient Portal - NovaTech”)
3. Select supported account types:
   • Accounts in this organizational directory only (single-tenant)
   • Accounts in any organizational directory (multi-tenant)
   • Accounts in any organizational directory and personal Microsoft accounts (multi-tenant + consumer)
4. Set the redirect URI (platform + URL)
5. Click Register

After registration, you get:

• Application (client) ID — the unique identifier your app uses to identify itself
• Directory (tenant) ID — identifies your Entra ID tenant
• Object ID — internal Entra ID object identifier

ℹ️ Scenario: Ravi registers the patient portal

💻 Ravi Patel at NovaTech Solutions is building a custom patient portal web app:

1. Name: “Patient Portal - NovaTech”
2. Account type: “Accounts in this organizational directory only” (only NovaTech staff need access — patients use a separate identity system)
3. Redirect URI: Web → https://portal.novatech.com/auth/callback
4. Platform: Web application (server-side, confidential client)

After registration, Ravi notes the Application (client) ID and Tenant ID — his developers will configure these in the app’s authentication middleware.

Configuring application authentication

Authentication flows

The platform type determines which OAuth 2.0 / OIDC flow the app uses:

Platform	Auth Flow	Token Handling	Example
Web app	Authorization code flow	Server-side (confidential client)	ASP.NET, Node.js backend
SPA	Authorization code flow with PKCE	Browser-side (public client)	React, Angular
Mobile/Desktop	Authorization code flow with PKCE	Native app (public client)	iOS, Android, WPF
Daemon/Service	Client credentials flow	No user interaction (app-only)	Background jobs, APIs

Platform configuration

In the app registration → Authentication blade:

• Add a platform → select Web, SPA, Mobile/Desktop, etc.
• Redirect URIs — where Entra ID sends the token after auth. Must match exactly.
• Front-channel logout URL — for single logout
• Implicit grant and hybrid flows — enable ID tokens and/or access tokens (implicit flow is legacy — avoid for new apps)

💡 Exam tip: Implicit vs authorization code

The exam may test when to use implicit flow vs authorization code + PKCE. Authorization code flow with PKCE is always preferred — it’s more secure because the token isn’t exposed in the browser URL. Implicit flow (where tokens are returned directly in the URL fragment) is legacy and should only be used when the app framework requires it. Microsoft’s recommendation: always use authorization code + PKCE for SPAs and native apps.

Configuring credentials

Your app needs a credential to prove its identity when requesting tokens.

Client secrets vs certificates

Feature	Client Secret	Certificate
What it is	A generated password string	An X.509 certificate (public key uploaded to Entra ID, private key kept by your app)
Security	Lower — can be leaked in code, logs, emails	Higher — private key never leaves your infrastructure
Rotation	Manual — create new secret, update app, delete old	Manual — upload new cert, update app trust
Maximum lifetime	Up to 2 years (24 months)	Up to 3 years
Microsoft recommendation	Development/testing only	Production workloads
Federated option	N/A	Workload identity federation — no secret or cert needed

💡 Exam tip: Secret expiry

Client secrets can be created with custom expiry up to 24 months (2 years). Microsoft previously allowed longer lifetimes but now enforces a 2-year maximum for new secrets. The exam may present scenarios where expired secrets cause authentication failures — the fix is to create a new secret and update the application’s configuration.

Configuring API permissions

API permissions define what your app can access. There are two types:

Feature	Delegated Permissions	Application Permissions
Acts as	The signed-in user	The application itself (no user context)
User present?	Yes — user must be signed in	No — runs without a user (daemon/service)
Permission scope	Limited to what the user can access	Org-wide access (powerful)
Consent	User or admin	Admin only
Example	User.Read (read my profile)	User.Read.All (read all users' profiles)
Risk level	Lower (user-scoped)	Higher (org-wide, no user boundary)

Adding permissions:

1. App registration → API permissions → Add a permission
2. Select the API (e.g., Microsoft Graph)
3. Choose Delegated or Application permissions
4. Select specific permissions (e.g., User.Read, Mail.Read)
5. For application permissions, click Grant admin consent for [tenant]

ℹ️ Scenario: Ravi configures API permissions for the patient portal

💻 Ravi needs his patient portal to:

• Show the signed-in user’s profile → Delegated: User.Read
• Show the user’s calendar for appointment scheduling → Delegated: Calendars.Read
• Send appointment reminder emails on behalf of the user → Delegated: Mail.Send

And a background job that runs nightly to sync all patient records:

• Read all users’ profiles (no user signed in) → Application: User.Read.All
• Read group memberships → Application: GroupMember.Read.All

Ravi’s admin grants admin consent for the application permissions. The delegated permissions prompt users to consent on first sign-in (or Ravi grants admin consent for the entire org to skip individual prompts).

Creating app roles

App roles provide role-based access control (RBAC) within your application. They’re emitted as claims in the token.

Creating roles in an app registration:

1. App registration → App roles → Create app role
2. Configure:
   • Display name: e.g., “Patient Records Admin”
   • Allowed member types: Users/groups, Applications, or Both
   • Value: The string that appears in the token claim (e.g., PatientRecords.Admin)
   • Description: What this role grants
3. Enable the role

Assigning roles:

• Go to the enterprise application (not the app registration)
• Users and groups → Add user/group → Select a role

The role value appears in the roles claim of the access token:

{
  "roles": ["PatientRecords.Admin"]
}

Your application code checks this claim to enforce authorisation.

💡 Exam tip: Application vs user roles

App roles with “Allowed member types: Applications” are for daemon/service apps — they let other service principals call your API with specific roles. For example, a background job might have the DataSync.Writer role, while a reporting service has DataSync.Reader. This is different from user-facing roles where humans get assigned.

🎬 Video walkthrough

🎬 Video coming soon

App Registrations Deep Dive — SC-300 Module 19

App Registrations Deep Dive — SC-300 Module 19

~14 min

Flashcards

Question

What is the difference between an app registration and a service principal?

Click or press Enter to reveal answer

Answer

An app registration is the global identity definition (blueprint) — it defines the app's client ID, redirect URIs, permissions, and credentials. A service principal (enterprise application) is the local instance in a specific tenant — it controls user access, SSO, and consent for that tenant. One app registration can have service principals in many tenants.

Click to flip back

Question

What is the difference between delegated and application permissions?

Click or press Enter to reveal answer

Answer

Delegated: the app acts on behalf of a signed-in user, scoped to that user's access. Application: the app acts as itself with no user context, accessing resources org-wide. Application permissions always require admin consent and are higher risk.

Click to flip back

Question

Why does Microsoft recommend certificates over client secrets?

Click or press Enter to reveal answer

Answer

Certificates are more secure — the private key never leaves your infrastructure, whereas client secrets can be leaked in source code, logs, or emails. Certificates support asymmetric cryptography (public key in Entra ID, private key in your app), making credential theft harder.

Click to flip back

Question

What is the maximum lifetime for a client secret in Entra ID?

Click or press Enter to reveal answer

Answer

24 months (2 years). Microsoft enforces this limit for new secrets. For longer-lived scenarios, use certificates or workload identity federation instead.

Click to flip back

Question

What OAuth 2.0 flow should a SPA (React/Angular app) use?

Click or press Enter to reveal answer

Answer

Authorization code flow with PKCE (Proof Key for Code Exchange). This is more secure than the legacy implicit flow because tokens aren't exposed in the browser URL. Microsoft recommends this for all new SPAs and native apps.

Click to flip back

Knowledge Check

Knowledge Check

Ravi is building a custom web application that only NovaTech employees should access. The app needs to read users' calendars when they are signed in. What should Ravi configure?

ASingle-tenant app registration with Delegated permission Calendars.ReadBMulti-tenant app registration with Application permission Calendar.ReadCSingle-tenant app registration with Application permission Calendars.ReadWrite.AllDMulti-tenant app registration with Delegated permission Calendars.ReadWrite

Check Answer

Knowledge Check

A background service at Meridian Health needs to sync all users' profiles from Microsoft Graph every night at 2 AM. No user is signed in during this process. What type of permission does Priya need to grant?

ADelegated permission: User.ReadBDelegated permission: User.Read.AllCApplication permission: User.Read.All with admin consentDApplication permission: User.Read with admin consent

Check Answer

Knowledge Check

Ravi's patient portal uses a client secret that expired yesterday. Users report they can't sign in. What should Ravi do?

AReset the application's client ID to generate a new secret automaticallyBExtend the expiry date of the existing secret in the Entra admin centerCDelete the app registration and create a new one to get fresh credentialsDCreate a new client secret in the app registration and update the app's configuration with the new secret value

Check Answer

Knowledge Check

A web application needs to call the Microsoft Graph API to read all users' profiles in the background (no user signed in). Which permission type is required?

ADelegated permissions with User.Read.AllBDelegated permissions with User.ReadWrite.AllCApplication permissions with User.Read.All and admin consentDNo permissions needed — Microsoft Graph is open by default

Check Answer

---

Next up: Defender for Cloud Apps: Discover & Control — how to discover shadow IT, connect cloud apps, and implement real-time access controls with Conditional Access App Control.