This chapter covers Teams app governance and app permissions, a critical topic for the MS-102 exam under objective 1.3 (Tenant Management). Understanding how to manage app lifecycle, permission requests, consent policies, and app governance policies is essential for securing your Microsoft 365 tenant. Approximately 10-15% of exam questions touch this area, often focusing on app permission types, consent settings, and governance policies. We will dive deep into the mechanics of app registration, Graph API permissions, consent flows, and how to enforce governance using Microsoft Entra ID and Teams admin center.
Jump to a section
Imagine a corporate office building where employees need badges to enter different areas. The building has a central security desk (Microsoft Entra ID) that issues badges. Each badge has specific permissions: some badges open the front door (basic sign-in), some open the finance floor (read financial data), some open the server room (administer resources). Apps are like visitors who need their own badges. When a developer creates an app, they request a badge template (application registration) that lists the doors the app needs to access. An admin must approve each door request (grant consent). Once approved, the app gets a badge (access token) that it shows at each door. The security desk checks the badge’s permissions before allowing entry. If the badge says 'read finance' but the app tries to write, the door denies entry. Also, badges expire after a set time (token lifetime), so the app must renew at the security desk. If an admin revokes a permission (e.g., remove 'read finance'), the next time the app tries to enter, its badge is invalid and must be reissued with updated permissions. This system ensures apps only access what they are explicitly authorized for, and admins have full audit logs of which apps entered which doors.
What is Teams App Governance and App Permissions?
Teams app governance refers to the policies and processes that control the lifecycle of apps within Microsoft Teams – from installation and permission granting to monitoring and removal. App permissions are the specific rights an app requests to access Microsoft 365 data via Microsoft Graph. These permissions are categorized into delegated (app acts on behalf of a signed-in user) and application (app runs as a background service without a user). The MS-102 exam expects you to understand how to manage these permissions through consent policies, app management in Teams admin center, and Microsoft Entra admin center.
How App Permissions Work Internally
When a developer registers an app in Microsoft Entra ID, they specify the required permissions in the app manifest. The app manifest is a JSON file that defines the app’s identity, required permissions, redirect URIs, and other properties. Permissions are referenced by their unique GUIDs (e.g., Mail.Read has ID 810c284a-ab6f-4b3f-b8bb-7c5a5e0a7a0c).
There are two types of permissions: - Delegated permissions: The app acts as the signed-in user. The permission scopes are combined with the user’s privileges. Example: User.Read allows reading the profile of the signed-in user. - Application permissions: The app runs without a user context. These are used for daemons or background services. Example: User.Read.All allows reading all users’ profiles.
When an app requests a permission, an admin (or user, depending on consent settings) must grant consent. Consent is recorded as a service principal in the tenant. The service principal is the local representation of the app in the tenant, and it holds the granted permissions.
Key Components, Values, Defaults, and Timers
Consent settings: In Microsoft Entra ID > Enterprise applications > Consent and permissions > User consent settings. Default: Users can consent to apps accessing company data for permissions classified as ‘low impact’. Admins can block user consent entirely or allow for specific permission classifications.
Permission classifications: Microsoft Entra ID allows admins to classify permissions into three categories: Low, Medium, High. This classification determines which permissions users can consent to without admin approval.
Admin consent workflow: If enabled, when a user attempts to consent to a permission that requires admin approval, a request is sent to designated reviewers. Default: disabled.
App permission policies in Teams: In Teams admin center > Teams apps > Permission policies. These policies control which apps (by app type: Microsoft, third-party, custom) users can install. Default: All app types allowed.
App setup policies: Control which apps are pinned to the Teams app bar and which are installed by default for users.
Token lifetimes: Access tokens for Microsoft Graph have a default lifetime of 60-90 minutes (configurable via token lifetime policies). Refresh tokens can last up to 90 days if not used.
App manifest version: The current schema for Teams apps is v1.12. The manifest includes fields like permissions (list of resource-specific consent), webApplicationInfo (for SSO), and graphPermissions (for Graph API scopes).
Configuration and Verification Commands
Using Microsoft Graph PowerShell:
# Get all service principals in the tenant
Get-MgServicePrincipal -All
# Get the service principal for a specific app
Get-MgServicePrincipal -Filter "displayName eq 'MyApp'"
# Get the delegated permissions granted to a service principal
Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId <id>
# Get application permissions (app roles) assigned
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId <id>Using Microsoft Graph API:
GET https://graph.microsoft.com/v1.0/servicePrincipalsTo configure consent policies:
# Enable admin consent workflow
Update-MgPolicyAdminConsentRequestPolicy -IsEnabled $trueHow It Interacts with Related Technologies
Teams app governance is tightly integrated with Microsoft Entra ID (for identity and permissions), Microsoft Purview (for compliance and data loss prevention), and Intune (for mobile app management). For example, if you block access to SharePoint Online via a conditional access policy, a Teams app that relies on SharePoint data may fail. Also, app permissions are evaluated at runtime: when an app calls Microsoft Graph, Azure AD checks if the service principal has the required permission (delegated or application) and if the user (if delegated) has the necessary role or license.
Governance Policies
App permission policies in Teams: Create custom policies to block all third-party apps, allow only specific apps, or control which apps are available to users.
Global app permission policy (Org-wide default): Controls the default behavior for all users. Can be overridden by custom policies assigned to specific users or groups.
App setup policies: Define which apps are pinned to the app bar and which are installed automatically when a user launches Teams.
Custom app policies: In Teams admin center, you can upload custom apps (LOB apps) and manage their availability.
Monitoring and Reporting
Audit logs: In Microsoft Purview compliance portal, audit logs record consent grants, app installations, and policy changes.
App usage reports: In Teams admin center, under Analytics & reports > Usage reports, you can see app usage by user.
Microsoft Entra ID sign-in logs: Show which apps users signed into and whether consent was granted.
Common Pitfalls
Over-privileged apps: Granting application permissions like Mail.Read.All to an app that only needs to read one user’s mail. The exam tests that you should follow least privilege.
Consent phishing: Users tricked into granting permissions to malicious apps. Mitigation: disable user consent for high-impact permissions.
Token theft: If an app’s client secret is compromised, an attacker can use application permissions. Mitigation: use certificates instead of secrets, and rotate them regularly.
Exam-Relevant Details
The difference between delegated and application permissions is frequently tested. Remember: delegated permissions combine with user privileges; application permissions are independent.
Consent types: static (admin consent for all users) vs. dynamic (user consent at runtime).
Permission classification: low, medium, high. Only low permissions can be consented by users without admin approval by default.
The admin consent workflow must be enabled before users can request admin consent.
Teams app permission policies are separate from Microsoft Entra ID consent policies – both must be configured for full governance.
Register an app in Entra ID
Navigate to Microsoft Entra admin center > App registrations > New registration. Provide a name, supported account types (e.g., Accounts in this organizational directory only), and a redirect URI (e.g., https://localhost for testing). Once registered, note the Application (client) ID and Directory (tenant) ID. These are used in authentication requests. The app is now represented as an application object in the tenant. This object includes the app manifest, which lists required permissions, but no permissions are granted yet. The next step is to configure API permissions.
Configure API permissions
In the app registration, go to API permissions > Add a permission. Choose Microsoft Graph. Then select Delegated permissions (e.g., User.Read) or Application permissions (e.g., User.Read.All). Add the required permissions. For delegated permissions, you must also set the 'Grant admin consent for [tenant]' button to pre-consent for all users. For application permissions, admin consent is always required. This step defines what the app can do. The permissions are stored in the app manifest under 'requiredResourceAccess' as an array of resourceAppId and resourceAccess (scopes/roles).
Grant admin consent
If the app needs admin consent, an admin must explicitly grant it. In the API permissions blade, click 'Grant admin consent for [tenant]'. This creates a service principal for the app (if not already existing) and assigns the requested permissions as OAuth2PermissionGrants (for delegated) or AppRoleAssignments (for application). The consent is recorded in the tenant’s consent grants. Alternatively, users can consent dynamically if allowed by policy. Admin consent is required for application permissions and for delegated permissions classified as high impact.
Create a Teams app package
To make the app available in Teams, you need a Teams app package: a zip file containing an app manifest (JSON) and icons. The manifest includes fields like id (GUID), version, developer, name, description, icons, permissions (resource-specific consent), and webApplicationInfo (for SSO). The permissions field lists the Microsoft Graph permissions the app needs (e.g., 'permissions': ['identity', 'user.read']). The manifest version must be v1.12. Upload this package to the Teams admin center or publish to the Teams app store.
Assign app permission policy
In Teams admin center > Teams apps > Permission policies, create a new policy or modify the global default. Set which app types are allowed: Microsoft, third-party, custom. You can also block specific apps by adding them to the blocked list. Assign the policy to users or groups. This controls whether users can install the app. If a policy blocks third-party apps, even if the app has admin consent, users cannot install it. This is a separate layer of governance from Entra ID consent.
Monitor and audit app usage
Use Microsoft Purview compliance portal > Audit to search for events like 'Consent to application', 'Add app to Teams', 'Remove app from Teams'. Also use Teams admin center > Analytics & reports > Usage reports to see active users per app. For deeper analysis, use Microsoft Graph API to list app consent grants: GET /oauth2PermissionGrants. Regularly review granted permissions to ensure least privilege. If an app is no longer needed, revoke its consent via Entra ID > Enterprise applications > [app] > Permissions > Revoke consent.
Enterprise Scenario 1: Restricting Third-Party Apps in a Financial Institution
A bank wants to allow only Microsoft-approved apps and a custom internal app in Teams. They create a custom app permission policy named 'Banking Policy' that blocks all third-party apps and allows only Microsoft apps and custom apps. They assign this policy to all employees via a group. They also disable user consent for all permissions in Entra ID, forcing all app consent to go through admin approval. When a manager tries to install a popular project management app, they receive an error that the app is blocked. They submit a request via the admin consent workflow, which goes to the IT security team. The security team reviews the app’s permissions (e.g., read calendar, write files) and denies it due to data sensitivity. This ensures no unauthorized app can access bank data.
Enterprise Scenario 2: Managing a Custom LOB App with High Permissions
A retail company develops a custom app that reads all users’ profiles and sends notifications. The app requires the User.Read.All application permission. The developer registers the app in Entra ID, adds the permission, and requests admin consent. The security team reviews the app and grants consent after verifying the app is internal and uses certificate-based authentication. They create a custom app setup policy that pins this app to the Teams app bar for all employees. They also create a conditional access policy requiring MFA for the app. The app is deployed to thousands of users. Later, a vulnerability is discovered; the security team revokes the app’s consent in Entra ID, causing the app to stop working immediately. They then update the app and re-grant consent. This demonstrates the need for proper governance and quick revocation.
Common Misconfigurations
Overly permissive user consent settings: Allowing users to consent to high-impact permissions leads to data leakage. The fix: set user consent to 'Do not allow user consent' or 'Allow for low impact permissions only'.
Not enabling admin consent workflow: Users get stuck when they need admin consent but have no way to request it. The fix: enable admin consent workflow in Entra ID > Enterprise applications > Consent and permissions.
Ignoring app permission policies in Teams: Even if an app has admin consent, it can still be blocked by Teams permission policies. Admins must check both Entra ID consent and Teams policies.
What MS-102 Tests on This Topic
The MS-102 exam objective 1.3 covers 'Manage app permissions and consent' and 'Manage Teams app governance'. Specifically, you need to know:
How to configure user consent settings in Microsoft Entra ID.
The difference between delegated and application permissions.
How to grant admin consent and when it is required.
How to create and assign Teams app permission policies and app setup policies.
How to manage custom app uploads and third-party app availability.
How to monitor app usage and audit consent grants.
Common Wrong Answers and Why
Confusing delegated and application permissions: A question might ask 'Which permission type allows an app to read all mailboxes without a signed-in user?' The wrong answer is 'Delegated permissions' because candidates think 'delegated' means the app acts on behalf of an admin. Correct: Application permissions.
Thinking consent is only done once: Some candidates believe that once admin consent is granted, it never expires. However, consent can be revoked, and permissions can change. Also, tokens expire, requiring refresh.
Assuming Teams permission policies override Entra ID consent: They are separate. An app can have admin consent but still be blocked by a Teams app permission policy. The exam tests that both layers must be considered.
Mixing up 'app permission policy' with 'app setup policy': Permission policy controls which apps can be installed; setup policy controls which apps are pinned/installed by default. Questions often ask which policy to use to block an app – answer: permission policy.
Specific Numbers and Terms
Permission classifications: Low, Medium, High. Low: permissions that read basic profile info. Medium: read access to sensitive data. High: write access or read all data.
Default user consent setting: 'Allow user consent for apps from verified publishers, for selected permissions (Low impact)'.
Admin consent workflow: must be enabled to allow users to request admin consent.
Teams app permission policy settings: 'Allow all apps', 'Allow specific apps and block all others', 'Block all apps', 'Allow all but block specific apps'.
App setup policy: 'Pinned apps' (up to 16 apps) and 'Installed apps'.
Custom app upload: requires 'Upload custom apps' setting to be enabled in Teams admin center > Org-wide app settings.
Edge Cases and Exceptions
Resource-specific consent (RSC): Teams apps can use RSC to request permissions for a specific team or chat, not the entire tenant. Example: an app requests to read messages in a specific channel. This is a new feature that the exam may test.
Permissions for Microsoft Graph vs. Teams-specific scopes: Some permissions are only available in Teams (e.g., ChannelMessage.Read.Group). Know that these are part of the Teams resource-specific consent model.
Consent for multi-tenant apps: If an app is registered in another tenant, your tenant’s admin must consent to allow users to install it. The app appears as an enterprise application after consent.
How to Eliminate Wrong Answers
If the question mentions 'without a user present' or 'background service', the answer is application permissions.
If the question asks about controlling which apps appear in the Teams app bar, the answer is app setup policy.
If the question asks about blocking an app from being installed, the answer is app permission policy.
If the question involves requesting admin consent by a user, the answer is admin consent workflow.
Delegated permissions require a signed-in user; application permissions do not.
Admin consent is always required for application permissions and for high-impact delegated permissions.
Teams app permission policies control app installation; app setup policies control app pinning and default installs.
User consent to permissions can be controlled via permission classifications (low, medium, high) in Entra ID.
The admin consent workflow must be enabled to allow users to request admin approval.
Resource-specific consent (RSC) allows apps to request permissions for a specific team or chat.
Audit logs in Purview track consent grants and app installations.
Revoking consent in Entra ID immediately stops the app from accessing data.
These come up on the exam all the time. Here's how to tell them apart.
Delegated Permissions
Requires a signed-in user
Combines app permissions with user privileges
Used for interactive apps (e.g., web, mobile)
Examples: User.Read, Mail.Read
User can consent (if allowed) or admin consent required
Application Permissions
No user required (background service)
App has its own identity and privileges
Used for daemons, background services, automation
Examples: User.Read.All, Mail.ReadWrite.All
Always requires admin consent
Mistake
Delegated permissions allow an app to access data without a user.
Correct
Delegated permissions require a signed-in user and combine the app's permissions with the user's privileges. Without a user, the app cannot use delegated permissions. Application permissions are used for unattended access.
Mistake
Granting admin consent once means the app has permanent access.
Correct
Admin consent can be revoked at any time by an administrator. Also, access tokens expire (default 60-90 minutes) and refresh tokens expire after 90 days of inactivity. The app must continuously refresh tokens to maintain access.
Mistake
Teams app permission policies are the same as Microsoft Entra ID consent policies.
Correct
They are separate. Entra ID consent policies control whether users can grant consent to app permissions (Graph API). Teams app permission policies control which apps (by type) can be installed in Teams. Both must be configured for full governance.
Mistake
All Microsoft Graph permissions are available for both delegated and application types.
Correct
Some permissions are only available as delegated (e.g., User.Read) and some only as application (e.g., User.Read.All). The Microsoft Graph documentation lists each permission's type. Not all permissions have both types.
Mistake
User consent settings in Entra ID apply to all apps uniformly.
Correct
User consent settings can be configured per permission classification (low, medium, high) and can also be scoped to specific apps via policies. Additionally, verified publishers may have different rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Delegated permissions allow an app to act on behalf of a signed-in user. The app’s access is limited to what the user can do. Application permissions allow the app to run without a user and have its own full privileges. For example, Mail.Read (delegated) lets the app read the signed-in user’s mail, while Mail.Read.All (application) lets the app read all mailboxes in the organization. Application permissions always require admin consent.
In Teams admin center, go to Teams apps > Permission policies. Create a new policy or edit the global (Org-wide default) policy. Under 'Microsoft apps', set to 'Allow all apps'. Under 'Third-party apps', set to 'Block all apps'. Under 'Custom apps', set as desired. Assign the policy to all users. This prevents users from installing any third-party app, but they can still use Microsoft apps.
The admin consent workflow allows users to request admin approval when an app requires permissions that the user cannot consent to themselves. To enable it: go to Microsoft Entra admin center > Enterprise applications > Consent and permissions > Admin consent settings. Turn on 'Admin consent requests' and specify reviewers (e.g., security team). Optionally, set a duration for requests. Once enabled, users see a prompt to request approval when they try to use an app that needs admin consent.
Go to Microsoft Entra admin center > Enterprise applications. Find the app (service principal). Under 'Permissions', you can revoke delegated permissions by clicking 'Revoke consent' for each permission grant. For application permissions, remove the app role assignment. Alternatively, you can delete the service principal entirely, which removes all permissions. The app will immediately lose access.
Resource-specific consent (RSC) allows a Teams app to request permissions for a specific resource, such as a team or a chat, rather than the entire tenant. For example, an app can request permission to read messages in a specific channel. RSC is defined in the app manifest under the 'permissions' field (e.g., 'ChannelMessage.Read.Group'). The app must be installed in the resource (team or chat) to use these permissions. RSC is useful for fine-grained access control.
By default, users can consent to apps that request permissions classified as 'low impact' and from verified publishers. The default setting is 'Allow user consent for apps from verified publishers, for selected permissions (Low impact)'. This means users can consent to permissions like User.Read (profile) but not Mail.Read (which is medium impact). Admins can change this to block all user consent or allow for more permissions.
You can use the Microsoft Entra admin center: go to Enterprise applications > Consent and permissions > User consent settings to see a list of apps with user consent. For a detailed audit, use Microsoft Purview compliance portal > Audit, and search for 'Consent to application' or 'Add OAuth2PermissionGrant'. You can also use PowerShell: Get-MgOauth2PermissionGrant to list all delegated permission grants.
You've just covered Teams App Governance and App Permissions — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?