Chapter 01Overview and core principle

Two directories, one trust relationship. The entire architecture reduces to this one figure.

The SaaS platform is defined once in the provider's tenant as an app registration. Each customer grants that application consent a single time. Doing so creates a local representation of the application in the customer's own Entra ID tenant: the enterprise application. That representation belongs to the customer. They administer it, restrict it and delete it — without any involvement from the provider.

The provider therefore gains no blanket access to customer data, only the permissions listed in the consent dialog and approved by the customer. In the architecture described here those permissions are read-only throughout: the platform reads data, it changes nothing in the tenant.

Fig. 1 — The app registration exists once. Each customer gets an independent enterprise application from it, fully under customer control.

1.1 What this document answers

What happens technically during onboarding and which objects are created.
Which Graph permissions are requested, why they are read-only, and how to verify that.
How the customer controls, after onboarding, which users may sign in to the SaaS platform — and which may not.
How access is audited and, if required, revoked completely.

1.2 Placeholders used in this document

All examples use generic placeholders. Replace them with the values from your onboarding letter:

Placeholder	Meaning	Example format
`<APP-ID>`	Application (client) ID of the SaaS platform	`7c4f1a2e-…-9b3d`
`<TENANT-ID>`	Directory ID of the customer tenant	`a91b…-e42c`
`<APP-NAME>`	Display name of the enterprise application	"SaaS platform"
`app.example.com`	Base URL of the SaaS platform	—

Chapter 02App registration vs. enterprise application

Both objects carry the same name and the same application ID. They are confused regularly all the same — with consequences for troubleshooting.

2.1 Terminology

Attribute	App registration	Enterprise application
Technical object type	`application`	`servicePrincipal`
Lives in the tenant of	The provider	The customer
Count	Exactly one, globally	One per customer tenant
Defines	Redirect URIs, requested permissions, app roles, certificates and secrets	The local instance: granted permissions, user assignments, visibility
Administered by	The provider	The customer
Application ID	Identical — `<APP-ID>` in both tenants
Object ID	Different — each object has its own

Rule of thumb

The app registration is the blueprint. The enterprise application is the copy that sits in the customer's directory. Every access control setting — chapter 6 — is made on the copy, that is, in the customer tenant.

2.2 What consent creates in the customer tenant

On admin consent, Entra ID creates the following objects in the customer's directory:

A service principal for the application itself — visible under Enterprise applications.
App role assignments (appRoleAssignment) for every granted application permission. They point to the Microsoft Graph service principal.
Where applicable, an OAuth2 permission grant (oauth2PermissionGrant) for the delegated permissions used when users sign in.
A service principal for Microsoft Graph itself, if one does not already exist.

No user accounts, groups, policies or directory entries are modified in the process. Consent is purely a grant of permissions.

2.3 Two separate paths — the key point

The platform uses two technically independent access paths. Separating them is a prerequisite for understanding chapter 6 correctly:

Fig. 2 — Path A decides who gets in. Path B determines what data the platform can read. The two are configured independently.

	Path A — sign-in	Path B — data retrieval
OAuth flow	Authorization code + PKCE (OIDC)	Client credentials
Permission type	delegated	application
User context	Yes — the token carries the signed-in user	No — the token belongs to the application
Typical scopes	`openid`, `profile`, `email`, `User.Read`	`User.Read.All`, `Reports.Read.All` and others
Controlled by	Assignment, app roles, Conditional Access	The scope of the admin consent granted
Runs when	On every user sign-in	On a schedule, in the background

Important

The "assignment required" setting and every Conditional Access policy act on path A. They do not affect app-only data retrieval on path B. To limit data retrieval, control the scope of consent and use the scoping mechanisms in section 3.4 — not user assignments. See section 6.5 for detail.

Chapter 03Permission model: read only

Every requested permission ends in .Read or .Read.All. Write permissions are absent from the manifest and cannot be added later by the provider without the customer noticing.

3.1 Delegated or application

	Delegated	Application
Acts	On behalf of the signed-in user	On behalf of the application itself
Effective scope	The intersection of the scope and the user's own rights	Tenant-wide, independent of users
Consent	User or administrator	Always an administrator
Used here for	Sign-in, showing the user's own profile	Background analytics, reporting

Application permissions are powerful precisely because they are not bounded by any user's rights. That is why restricting them to read access is the decisive safeguard here — supplemented by the scoping options in section 3.4.

3.2 Requested permissions

Treat the table below as a template. What counts is the list shown in the consent dialog, which you can read out for yourself after onboarding as described in section 3.5.

Permission	Type	Why it is needed
`User.Read`	del.	Displaying the signed-in user's name and photo
`User.Read.All`	app	Resolving user objects, mapping licences and attributes
`Group.Read.All`	app	Group and team membership for reporting and mapping
`Organization.Read.All`	app	Tenant master data and licence inventory
`Reports.Read.All`	app	Microsoft 365 usage reports (Teams, Exchange, SharePoint, OneDrive)
`AuditLog.Read.All`	app	Sign-in and audit logs for activity analysis
`Directory.Read.All`	app	Cross-cutting directory queries, where the individual permissions above are insufficient
`Policy.Read.All`	app	Reading policy configuration for security assessments
`Sites.Selected`	app	SharePoint access, explicitly limited to individually released sites

Test to apply

If a requested permission contains Write, ReadWrite, Manage, FullControl, or All in the sense of Directory.AccessAsUser.All, it is not read-only. Insist on a justification before granting consent.

3.3 Why `Directory.Read.All` deserves scrutiny

Directory.Read.All is read-only but very broad: it covers virtually the whole directory, including objects an application rarely needs. Where possible the platform should request the narrower User.Read.All, Group.Read.All and Organization.Read.All instead. Ask the provider which specific endpoints require this permission.

3.4 Narrowing access further

For individual workloads Microsoft offers mechanisms that confine even tenant-wide application permissions to a subset. They are configured in the customer tenant and take effect independently of consent.

Mechanism	Workload	Effect
`Sites.Selected`	SharePoint / OneDrive	Access only to sites explicitly released via Graph — no release, no access.
Application access policy	Exchange Online	Confines mailbox access to the members of a security group.
Resource-specific consent	Microsoft Teams	Access only to those teams where the app has been installed.
Administrative units	Entra ID	Scoping inside the directory; applies to directory roles, not to app permissions.

PowerShell · application access policy for Exchange Online

Connect-ExchangeOnline

New-ApplicationAccessPolicy `
  -AppId "<APP-ID>" `
  -PolicyScopeGroupId "saas-scope@contoso.com" `
  -AccessRight RestrictAccess `
  -Description "Confines SaaS platform mailbox access to the scope group"

# Test the effect for a specific mailbox
Test-ApplicationAccessPolicy -Identity "anna.smith@contoso.com" -AppId "<APP-ID>"

3.5 Verifying the granted permissions yourself

After onboarding you can read out exactly what the application was granted. Make this check part of every acceptance review.

Portal: Microsoft Entra admin center → Identity → Applications → Enterprise applications → <APP-NAME> → Security → Permissions

PowerShell · Microsoft.Graph SDK

Connect-MgGraph -Scopes "Application.Read.All","Directory.Read.All"

$sp = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

# Application permissions (path B)
Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
  ForEach-Object {
    $roleId = $_.AppRoleId
    [pscustomobject]@{
      Type       = "Application"
      Permission = ($graph.AppRoles | Where-Object Id -eq $roleId).Value
      GrantedOn  = $_.CreatedDateTime
    }
  } | Sort-Object Permission | Format-Table -AutoSize

# Delegated permissions (path A)
Get-MgOauth2PermissionGrant -Filter "clientId eq '$($sp.Id)'" |
  Select-Object ConsentType, PrincipalId, Scope | Format-List

Expect a list in which every line ends in .Read or .Read.All. If the output differs from the list contractually agreed, escalate.

Chapter 04The onboarding process

A single, deliberate administrative act. It takes a few minutes and can be reversed at any time.

4.1 Prerequisites

Someone holding the Global Administrator or Privileged Role Administrator role. Cloud Application Administrator is not sufficient for Graph application permissions.
The customer's directory ID (<TENANT-ID>).
A browser session with only the administrative account signed in — a private window avoids mix-ups.
If consent policies are active in the tenant: knowledge of whether an approval workflow has to be followed.

4.2 Step by step

Invitation from the provider

The customer receives an onboarding link with the <APP-ID> embedded. The link leads to the platform's onboarding page first, not directly to Microsoft.
Starting admin consent

The platform redirects to Microsoft's consent endpoint. The state parameter carries a random, single-use identifier that is used to match the returning session.
Consent URL
```
https://login.microsoftonline.com/<TENANT-ID>/v2.0/adminconsent
  ?client_id=<APP-ID>
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fonboarding%2Fcallback
  &scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
  &state=8f2c41ae-7b90-4d13-9f0e-2ac6d5b1e774
```
Microsoft also accepts /organizations/oauth2/v2.0/authorize with prompt=admin_consent. Both produce the same result; the first is less ambiguous because it names the target tenant explicitly.
Sign in and review the dialog

Microsoft prompts for sign-in and then displays the complete list of requested permissions. Check three things at this point:
- Does the application name shown match the one you expect?
- Is the publisher verified (blue checkmark)? An unverified publisher is not a reason to stop, but it is a reason to ask.
- Does the list contain read permissions only? The dialog describes write permissions with wording such as "read and write".
The phrase "on behalf of your organization" means the consent applies tenant-wide, not just to your own account. For application permissions this is technically unavoidable.
Granting consent

On confirmation, Entra ID creates the service principal and the permission assignments. The operation is recorded in the audit log as Consent to application and Add app role assignment to service principal.
Redirect back to the platform

Microsoft calls the redirect URI and passes tenant, state and admin_consent=True. The platform validates the state value, discards it, and registers the tenant ID.
Redirect — success case
```
https://app.example.com/onboarding/callback
  ?admin_consent=True
  &tenant=<TENANT-ID>
  &state=8f2c41ae-7b90-4d13-9f0e-2ac6d5b1e774
```
If the process is cancelled, error=access_denied is passed instead. No service principal is created and no permissions are granted.
Verification by the platform

The platform acquires a first app-only token for the new tenant and performs a minimal read. Only when that succeeds is onboarding considered complete. Expect a delay of a few minutes while the permissions replicate.
Turning on access control

The customer now configures the enterprise application: require assignment, assign groups, apply Conditional Access. That is the subject of chapter 6 and should happen before the platform is released to end users.

Alternative

Some organisations do not permit consent through an external link. In that case the service principal can be created manually in advance and the permissions assigned individually. The route via Enterprise applications → Consent and permissions → Admin consent requests also works, provided the approval workflow is enabled in the tenant.

PowerShell · create the service principal in advance

Connect-MgGraph -Scopes "Application.ReadWrite.All","AppRoleAssignment.ReadWrite.All"

# Creates the enterprise application in your own tenant - still without permissions
New-MgServicePrincipal -AppId "<APP-ID>"

4.3 What the provider stores after onboarding

For transparency the provider should disclose what is recorded per customer. The following is customary and sufficient:

Tenant ID and default domain
Timestamp of consent and identifier of the consenting person
The list of permissions granted at the time of consent
Status of the verification check

No customer credentials are stored — there are none. Authentication happens exclusively via the provider's certificate against the respective customer tenant.

Chapter 05Authentication in operation

After onboarding the platform authenticates separately for each customer. A token is only ever valid for one tenant.

5.1 Acquiring a token

HTTP · client credentials against the customer tenant

POST https://login.microsoftonline.com/<TENANT-ID>/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id=<APP-ID>
&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default
&grant_type=client_credentials
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=<signed-JWT>

The .default scope means "every permission this tenant has granted the application". If permissions are revoked they disappear from the next token automatically. There is no way for a token to carry more rights than consent granted.

5.2 Application credentials

Method	Assessment
Client secret	Simple, but a copyable secret with a limited lifetime. Not recommended for production multi-tenant applications.
Certificate	The private key stays in a key vault or HSM. A good standard.
Federated identity credential	No long-lived secret at all; the workload identity of the hosting environment signs the assertion. The preferred method.

This matters to the customer because a compromised provider credential would open access to every onboarded tenant. As part of vendor due diligence, ask which method is used, how often keys are rotated, and where they are held.

5.3 Behaviour when permissions are revoked

If the service principal is deleted, the token request fails with AADSTS700016.
If individual permissions are removed, tokens are still issued — the affected Graph calls then return 403 Forbidden.
Tokens already issued remain valid until they expire, typically 60 to 90 minutes. Revoke-MgUserSignInSession affects user tokens only, not app-only tokens.

Note

An app-only token cannot be invalidated early. For an immediate and complete stop, delete the enterprise application — see chapter 8. After that no new token can be issued.

Chapter 06Access control by the customer

After onboarding, the decision about who may sign in to the platform rests entirely with the customer. It is made in the enterprise application — not at the provider.

With no further configuration, the Entra ID default applies: every user in the tenant can sign in. That is rarely what anyone wants. The four layers below take effect independently of one another; in practice layers 1 and 3 are almost always combined.

Layer 1Entra ID · the basic decision

Assignment required

Determines that only explicitly assigned users and groups may open the application at all. The single most effective switch.

Layer 2Entra ID · differentiation

App roles

Distinguishes between roles such as reader, analyst and administrator among the assigned people. The role is passed to the platform in the token.

Layer 3Entra ID · conditions

Conditional Access

Ties sign-in to conditions: MFA, compliant device, location, risk level, session lifetime.

Layer 4SaaS platform

In-product permissions

Fine-grained control inside the application: which reports, tenant areas or export functions a role can see.

6.1 Layer 1 — assignment required

This is the foundational measure. With the switch on, Entra ID rejects the sign-in of any unassigned user before the platform is ever contacted.

Portal: Entra admin center → Enterprise applications → <APP-NAME> → Manage → Properties → Assignment required? → Yes → Save

Then record who is entitled:

Portal: same application → Manage → Users and groups → Add user/group

Setting	Effect on sign-in
Assignment required = No (default)	Any user in the tenant can sign in. Assignments then only govern visibility in the My Apps portal.
Assignment required = Yes	Only assigned users and members of assigned groups can sign in. Everyone else receives `AADSTS50105`.

Recommendation

Assign groups, not individuals. A security group such as SEC-SaaS-Platform-Users can be populated through your existing processes, is auditable, and survives staff changes. Assigning groups requires at least an Entra ID P1 licence; without P1 only individual assignments are possible.

PowerShell · require assignment and entitle a group

Connect-MgGraph -Scopes "Application.ReadWrite.All","AppRoleAssignment.ReadWrite.All","Group.Read.All"

$sp = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"

# Turn on layer 1
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AppRoleAssignmentRequired:$true

# Entitle a group (default access, no specific role)
$grp = Get-MgGroup -Filter "displayName eq 'SEC-SaaS-Platform-Users'"

New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $sp.Id `
  -PrincipalId  $grp.Id `
  -ResourceId   $sp.Id `
  -AppRoleId    ([Guid]::Empty)

# Check: who is currently assigned?
Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $sp.Id |
  Select-Object PrincipalDisplayName, PrincipalType, CreatedDateTime |
  Sort-Object PrincipalDisplayName | Format-Table -AutoSize

[Guid]::Empty represents default access with no specific role. Where app roles are defined, use their ID instead — see the next section.

6.2 Layer 2 — app roles for differentiation

If the application defines app roles, they appear as choices during assignment. The assigned role is passed in the ID token as the roles claim; the platform reads it and unlocks the corresponding features. The customer thus controls not only whether someone signs in, but with what.

Example role	Claim value	Typical entitlement in the platform
Reader	`Reports.Viewer`	View reports, no export
Analyst	`Reports.Analyst`	View and export reports
Administrator	`Tenant.Admin`	Configuration, user management, data deletion

PowerShell · list available roles and assign one

$sp = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"

# Which roles does the application offer?
$sp.AppRoles | Where-Object IsEnabled |
  Select-Object DisplayName, Value, Id, @{n='For';e={$_.AllowedMemberTypes -join ','}} |
  Format-Table -AutoSize

# Assign a group to the "Tenant.Admin" role
$role = $sp.AppRoles | Where-Object Value -eq "Tenant.Admin"
$grp  = Get-MgGroup -Filter "displayName eq 'SEC-SaaS-Platform-Admins'"

New-MgServicePrincipalAppRoleAssignment `
  -ServicePrincipalId $sp.Id -PrincipalId $grp.Id `
  -ResourceId $sp.Id -AppRoleId $role.Id

Alternative

Instead of app roles the platform can evaluate group membership through the groups claim. App roles are preferable: they are application-specific, they do not run into the claim size limit, and they do not expose your entire group structure to the application.

6.3 Layer 3 — Conditional Access

Assignment decides who may. Conditional Access decides under what conditions. The policy is targeted specifically at the enterprise application.

Portal: Entra admin center → Protection → Conditional Access → Policies → New policy → Target resources → Cloud apps → Select apps → <APP-NAME>

Requirement	How to express it in the policy
Enforce multifactor authentication	Grant → Require multifactor authentication
Allow managed devices only	Grant → Require device to be marked as compliant (or Hybrid Entra joined)
Limit access to certain countries	Conditions → Locations → exclude a named location; Grant → Block
Limit session lifetime	Session → Sign-in frequency, e.g. 8 hours
Block on elevated sign-in risk	Conditions → Sign-in risk → High; Grant → Block (requires P2)
Restrict access from unmanaged browsers	Session → Use app enforced restrictions, or Conditional Access App Control

Before you enable

Run new policies in report-only mode first and review the results in the sign-in logs. Exclude at least one break-glass account from every policy. Both are general ground rules, independent of this application.

6.4 Layer 4 — permissions inside the platform

What a signed-in user may see and do in the application follows from the role passed in the token and from in-product configuration. This layer does not replace layers 1 to 3: someone who cannot get past Entra ID needs no in-product permission. Conversely, permission to sign in does not by itself grant access to every report.

Clarify with the provider whether the platform derives roles exclusively from the token or maintains a parallel user directory of its own. Only in the first case does removing a group membership in Entra ID take effect immediately.

6.5 What assignment does not do

Common misconception

"Assignment required" and Conditional Access act on user sign-ins only — path A from section 2.3. App-only data retrieval on path B uses no user context and is untouched by either mechanism.

Concretely: if a user is not assigned to the application, they cannot sign in. The platform's background analytics will still read their directory and usage data, provided User.Read.All was granted. To limit that as well, you have these options:

Goal	Effective lever	Not effective
Restrict sign-in	Assignment required, app roles, Conditional Access	Revoking Graph permissions
Restrict data scope	Revoke individual application permissions; `Sites.Selected`, application access policy, RSC	User assignments
Stop everything immediately	Disable or delete the enterprise application	Changing individual assignments

PowerShell · revoke a single application permission

$sp    = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"
$graph = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
$role  = $graph.AppRoles | Where-Object Value -eq "AuditLog.Read.All"

Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $sp.Id |
  Where-Object AppRoleId -eq $role.Id |
  ForEach-Object {
    Remove-MgServicePrincipalAppRoleAssignment `
      -ServicePrincipalId $sp.Id -AppRoleAssignmentId $_.Id
  }

Revoking individual permissions will cause errors or incomplete reporting in the platform. Coordinate it with the provider.

6.6 Visibility and self-service

Hide from the My Apps portal: Properties → Visible to users? → No. The application disappears from myapplications.microsoft.com but remains reachable by direct link. This is a display setting, not a security control.
Block sign-in entirely: Properties → Enabled for users to sign-in? → No. All user sign-ins are blocked regardless of assignment. App-only access continues.
Self-service access: under Self-service, users can request access themselves and nominated approvers decide. Useful at scale; requires P1.

6.7 Reviewing access regularly

With Microsoft Entra ID Governance (P2 or an Entra ID Governance licence) you can set up a recurring access review for the application. Managers or nominated reviewers periodically confirm whether an assignment is still needed; assignments that are not confirmed are removed automatically.

Portal: Entra admin center → Identity Governance → Access reviews → New access review → Applications → <APP-NAME>

Without that licence, a scheduled report serves the same purpose: export the output of Get-MgServicePrincipalAppRoleAssignedTo quarterly and have the business owners review it.

6.8 Worked examples

Only the IT department may sign in

Create and populate the security group SEC-SaaS-Platform-Users.
Set Assignment required to Yes on the enterprise application.
Assign the group under Users and groups.
Verify with an unassigned test account that sign-in is rejected with AADSTS50105.

Everyone may read, two people may configure

Create two groups: SEC-SaaS-Platform-Users and SEC-SaaS-Platform-Admins.
Assign the first to the Reader role and the second to the Administrator role.
Confirm that the platform evaluates the roles claim — ask the provider if in doubt.

Access only from the corporate network on a managed device

Define a named location for the company's sites.
Apply a Conditional Access policy to the application: Grant → Require compliant device.
Add a second policy: all locations except the named location → Block.
Evaluate both in report-only mode first, then enable them.

Chapter 07Logging and evidence

Every access is traceable in the customer tenant — both the sign-ins of people and the background access of the application.

Log	Where	Contents
Interactive sign-ins	Enterprise application → Sign-in logs, Interactive user sign-ins tab	Who signed in, when and from where; the Conditional Access policies applied; the error code on rejection
Service principal sign-ins	Sign-in logs, Service principal sign-ins tab	Every token request made by the application without a user context
Audit log	Entra admin center → Monitoring → Audit logs	Consent grants, permission changes, assignments, deletion of the service principal
Microsoft Graph activity logs	Diagnostic settings → Log Analytics / storage	Individual Graph calls including endpoint and response code

The Graph activity logs are the sharpest instrument: they show, request by request, which endpoints the application actually called. That lets you verify the read-only assurance empirically — with pure read access only GET requests appear. Enabling them requires a diagnostic setting, an appropriate licence, and a destination for the data.

KQL · analyse the application's Graph calls

MicrosoftGraphActivityLogs
| where AppId == "<APP-ID>"
| where TimeGenerated > ago(7d)
| summarize Requests = count() by RequestMethod, ResponseStatusCode
| order by Requests desc

KQL · rejected sign-in attempts against the application

SigninLogs
| where AppId == "<APP-ID>"
| where ResultType != 0
| project TimeGenerated, UserPrincipalName, ResultType, ResultDescription, IPAddress
| order by TimeGenerated desc

Chapter 08Offboarding and revocation

Access ends without any action by the provider. One step in the customer tenant is enough.

8.1 Immediate stop

Portal: Enterprise applications → <APP-NAME> → Manage → Properties → Delete

PowerShell · remove the enterprise application

Connect-MgGraph -Scopes "Application.ReadWrite.All"

$sp = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"
Remove-MgServicePrincipal -ServicePrincipalId $sp.Id

Deleting it removes all permission assignments and consent grants. No new tokens are issued; requests fail with AADSTS700016. The deleted service principal stays in a recoverable state for 30 days and can be restored within that window if needed.

8.2 Graduated alternatives

Measure	Effect	When to use it
Disable sign-in	No more user sign-ins; data retrieval continues	Temporarily suspending the interface
Remove all assignments	Nobody can sign in; data retrieval continues	Reorganising who is entitled
Revoke individual Graph permissions	The affected reports break	Reducing the data scope
Delete the service principal	Both paths end completely	End of contract, security incident

8.3 Data deletion at the provider

Deleting the enterprise application ends access but removes no data already held by the provider. Request deletion in writing and ask for confirmation of:

Deletion of stored analytics data and the retention period until final removal
Treatment of backups and their expiry date
Removal of the tenant entry from the platform's registry

Chapter 09Error conditions and remedies

The most common messages during onboarding and in operation, ordered by what they actually mean.

Code	Meaning	Remedy
`AADSTS50105`	The signed-in user is not assigned to the application.	Assign the user or their group under Users and groups — or deliberately set Assignment required to No.
`AADSTS90094`	The requested permissions need administrator consent.	Have a Global Administrator grant consent, or raise a request through the admin consent workflow.
`AADSTS65001`	No consent exists for this application.	Complete the onboarding process from chapter 4.
`AADSTS700016`	The application is not present in the directory.	The enterprise application was deleted, or the wrong tenant was addressed. Recreate the service principal or repeat consent.
`AADSTS7000215`	Invalid client secret.	On the provider's side: an expired or incorrect secret. No action needed in the customer tenant.
`AADSTS53003`	Access blocked by a Conditional Access policy.	Open the sign-in log, go to the Conditional Access tab, identify the policy that triggered and adjust it.
`403 Forbidden` (Graph)	Token valid, permission for the endpoint missing.	Check the granted permissions per section 3.5; renew consent if necessary. For Exchange and SharePoint access, also check the scoping policies from 3.4.
`429 Too Many Requests`	Throttling by Microsoft Graph.	On the provider's side: honour `Retry-After` and batch requests. Not a configuration error.
Consent granted, access still fails	Replication delay in the directory.	Wait 15 to 30 minutes. If the error persists, check the permissions per section 3.5.
No consent button shown	The signed-in account lacks the required role.	Sign in with an account holding the Global Administrator role.

Chapter 10Checklists

10.1 Before granting consent

The requested permissions are documented in writing and each one is justified.
Every permission ends in .Read or .Read.All.
The publisher is verified; application name and application ID match the contract.
Data processing agreement, storage location and retention periods are settled.
The provider's authentication method against Entra ID is known (certificate or federated credential).
The consenting person holds the Global Administrator role.

10.2 Immediately after onboarding

Granted permissions read out and reconciled with the agreed list.
Assignment required set to Yes.
Entitled group created, populated and assigned.
App roles mapped, where the application offers them.
Conditional Access policy created and validated in report-only mode.
Rejection of an unassigned test account verified.
The consent event captured from the audit log and filed.

10.3 Ongoing operation

Quarterly review of assignments, by access review or export.
Semi-annual reconciliation of granted permissions against the agreed baseline.
Sign-in logs checked for unusual rejections and locations.
Provider contacts and escalation path kept current.
Offboarding procedure documented and executable in an emergency without consulting anyone.

Chapter 11Glossary

Admin consent: Tenant-wide approval by an administrator. Technically mandatory for application permissions, since these are not tied to any user.
App role: A role defined by the application, assigned to users or groups and passed in the token as the roles claim.
Application permission: A permission that acts without a user context and applies tenant-wide. Always requires administrator consent.
Client credentials flow: The OAuth 2.0 flow in which the application authenticates with its own credentials — with no person involved.
Conditional Access: The Entra ID policy engine that ties access to conditions such as MFA, device compliance or location.
Delegated permission: A permission that acts on behalf of the signed-in user and never exceeds that user's own rights.
Enterprise application: The portal's name for the service principal — the local instance of an application in the customer tenant.
Multi-tenant application: An app registration made available to accounts from any Entra ID directory.
Service principal: The security object representing an application in a specific directory. It carries the permissions and assignments.
The .default scope: A collective identifier requesting every permission granted to an application in the given tenant — no more, no less.
Assignment required: The service principal property appRoleAssignmentRequired. When set, only assigned users may sign in.

Articles in this category