Permissions and Consent

Chapters 4 and 5 were about credentials: the integration proving who it is. This chapter is about what happens after it proves who it is. An integration with a perfectly valid secret and certificate can still fail, because Entra asks three further questions before it issues a token: what is this application allowed to do? (permissions and consent), who is allowed to use it? (assignment), and under what conditions? (Conditional Access, MFA and guest rules). These are the quiet causes. Nothing has expired, and nothing in your system has changed. Someone in the client's tenant changed a rule.

Part 1: Permissions — What the Application May Do

Back in Chapter 2 you met the two ways an application accesses data. Microsoft's permissions overview calls them delegated access (the application acts on behalf of a signed-in user) and app-only access (the application acts as itself, with no user present). Each uses a different kind of permission, and the difference decides who must approve it.

For your integration, the practical reading is this. If it signs users in and then calls an API for them (an OIDC integration), it uses delegated permissions, even if that is just the basic openid and profile sign-in scopes. If it runs in the background and calls an API for itself (the client-credentials pattern from Chapter 3, whose token request asks for resource/.default), it uses application permissions, which only an administrator can approve. SAML single sign-on and SCIM provisioning don't use this permission model for their core job; their access is governed by the enterprise application's configuration and the provisioning credential instead.

Part 2: Consent — Who Said Yes

A permission listed on a registration is only a request. Consent is the recorded approval. Without a record of consent covering what the application asks for, Entra won't issue the token.

User consent

When a user signs in, Entra checks whether consent for the required permissions already exists. If there is no record of user or admin consent, the user is shown a consent prompt listing the permissions and the publisher. If they accept, the consent is recorded and they usually don't need to consent again. But user consent is possible only where the tenant allows it for that application and those permissions. If it's disabled, or the user isn't allowed to consent to what's requested, the user is not prompted at all, which can look to the user like a plain failure with no explanation.

The tenant's user-consent setting is one of three built-in options, according to Microsoft:

• Disable user consent: users can't grant permissions to applications. They keep signing in to applications they already consented to, or that an administrator consented to for them, but can't approve anything new.
• Users can consent to applications from verified publishers or your organisation, but only for permissions you select: only permissions classified as low impact, and only for verified-publisher or in-tenant applications.
• Users can consent to all applications: any permission that doesn't itself require admin consent.

A client may well have changed this setting as part of a security tidy-up. If it moved from the third option to the first, a newly onboarded user of your product, who needs consent for the first time, suddenly can't complete sign-in, while existing users carry on.

Admin consent

Some permissions can only be consented to by an administrator: application permissions, and many high-privilege delegated ones. Authentication requests prompt for admin consent if consent wasn't granted and one of those permissions is requested. Custom application scopes aren't treated as high-privilege. Administrators can also consent on behalf of the whole organisation, after which users aren't prompted. Microsoft's page on granting consent lists who can do it:

That table matches Chapter 5's note that Graph application permissions need a higher-privileged person than most client administrators expect. Plan for a request to travel upward.

Where to see consent in the portal

The admin consent URL

When the client's administrator hasn't granted consent, the easiest route is often a link they can open. Microsoft documents the tenant-wide admin consent URL format, which needs only the application's client ID:

The administrator should still review the listed permissions before accepting. Never ask for consent to be granted blindly, and never send a link that you cannot explain. Your product may have its own "connect" page that builds this URL for the customer; check how yours does it before improvising one.

The admin consent workflow

If users aren't allowed to consent, the tenant may have an admin consent workflow. A user signing in sees an Approval required window, types a justification and selects Request approval; a Request sent message follows. Designated reviewers are notified, and the user is emailed when the request is approved, denied or blocked. Microsoft notes that if a user sends several requests, only the first is submitted. So "I clicked request approval three days ago and nothing happened" is a real, common support case: the answer is to find out who the reviewers are and whether anyone is watching their queue.

Part 3: Assignment — Who May Use the Application

Chapter 5 introduced the Assignment required? property. This is its mechanism. Even after tenant-wide admin consent, who can sign in is a separate decision. Microsoft is explicit that granting tenant-wide admin consent allows all users to access the application unless otherwise restricted, and that the way to restrict it is to require user assignment and then assign users or groups.

• With Assignment required = Yes, only assigned users, groups and applications can obtain a token. Unassigned users are refused.
• Assign under Entra ID > Enterprise apps > <app> > Users and groups > Add user/group. If the application defines no roles, the role is Default Access (its ID is all zeros).
• Roles that can assign: Cloud Application Administrator, Application Administrator, User Administrator, or the owner of the service principal.
• Group assignment needs Microsoft Entra ID P1 or P2. Assigning a group gives access to the users in that group; it does not cascade to nested groups, and nested group membership is not currently supported.
• Microsoft adds that applications that require user assignment must have their permissions consented to by an administrator, even if the tenant's user-consent policy would otherwise allow users to consent.

Part 4: Conditional Access and MFA — The Conditions

Conditional Access is Entra's policy engine. Microsoft describes policies at their simplest as if-then statements: if a user wants to access a resource, then they must complete an action. It gathers signals (user, group, IP location, device, application, sign-in risk) and makes a decision: block access, or grant access with requirements such as multifactor authentication, a compliant or hybrid-joined device, an approved client app, a password change or acceptance of terms of use. Two facts from Microsoft's overview matter for troubleshooting:

• Policies are enforced after first-factor authentication is completed. So a user can type the right password and then be stopped by a policy.
• It needs Microsoft Entra ID P1 licences (Microsoft 365 Business Premium also includes it). Risk-based policies need Entra ID P2. When licences expire, Microsoft says policies aren't automatically disabled or deleted, but can't be updated.

Conditional Access lives at Entra ID > Conditional Access, readable by someone with at least the Security Reader role. The Policies page lists them, including report-only policies (which log what would have happened without enforcing), and has a What If tool.

Two ways this hits an integration

MFA and sign-in prompts

A new policy that demands MFA is a common surprise. For interactive sign-in, the user is simply prompted. But if your integration uses a flow that can't show a prompt (a non-interactive background refresh, an embedded browser, a legacy protocol), the request fails with a message saying interaction or MFA is required (Chapter 3's interaction_required family; the matching AADSTS numbers are below). Microsoft lists "blocking sign-ins for users who try to use legacy authentication protocols" as a commonly applied policy, which can break older connectors silently.

Part 5: Guests and Cross-Tenant Settings

If the people who cannot sign in are guests (B2B users from another organisation, or your own support staff signing in to the client's tenant), look at the cross-tenant rules. Microsoft's overview describes cross-tenant access settings that control inbound access (users from external organisations reaching the client's resources) and outbound access (the client's users reaching others). Key facts:

• By default, B2B collaboration with other Entra organisations is enabled, and the default settings apply to all external organisations unless organisation-specific settings exist, which take precedence.
• Access settings can be scoped to specific users, groups and applications, and blocking inbound access for all external users means all applications are blocked too. Microsoft warns that changing defaults to block can break existing business-critical access.
• Trust settings decide whether the client's Conditional Access policies accept the MFA and device claims from a guest's home tenant. If MFA isn't trusted, a guest who already did MFA at home is asked again. If a policy requires a compliant device and the claim isn't trusted, the guest is blocked.
• Configuring these settings needs at least Security Administrator, and targeting specific users or apps requires a Microsoft Entra ID P1 licence on the tenant being configured.
• Changes are recorded in the audit logs under the category CrossTenantAccessSettings (Chapter 7).

Also remember the plainer cause: the guest account may simply not exist yet in the client's tenant, which produces its own errors (below).

Reading the Errors

Chapter 7 covers the sign-in logs and error codes in depth. For now, here are the codes most related to this chapter, with the meaning given in Microsoft's current error-code reference (the error name is the part before the dash). Treat the code as a pointer, then confirm in the sign-in log.

Who Is Affected? A Triage Table

Before opening any logs, the pattern of who fails already points at a gate. This is the most useful one-minute habit in the chapter.

Hands-On Exercises

All three use fictional organisations and values. Never put real secrets, tokens or tenant details into practice notes.