Clarification on SharePoint Macro Consent Flow and Permissions

prolaborate devteam 0 Reputation points
2026-06-17T12:32:03.7933333+00:00

Hi Team,

We have a customer using SharePoint in a secure environment. While configuring the Prolaborate SharePoint Macro on their site, a consent popup is displayed during the approval process.

Previously, our macro implementation used the Admin Consent flow. Based on the customer’s security and approval requirements, we have modified the consent to use the User Consent flow instead.

The customer has requested additional clarification regarding the consent process. Specifically, they would like to understand:

User's image

  • The exact API calls triggered for these two consents
    • View your basic profile
      • Maintain access to data you have given it access to
      • The permissions being requested from Microsoft Graph or SharePoint
      • Whether the application requests any tenant-wide or high-privilege permissions
      • Whether minimal permissions such as Sites.Selected can be used instead of broader scopes

Current concern:

  • The customer feels the current permission request is too broad for approval within their secure environment (Banking customer).

Reason:

  • Their internal approval process requires clear visibility into the exact API and permission scopes being requested, as different permissions are reviewed and approved by different internal teams (for example, User.Read is managed by the Identity team).

From our implementation side, we are using only custom APIs and are not directly calling Microsoft Graph APIs.

This information will help us provide a clear response to the customer and support their internal approval process.

Microsoft 365 and Office | SharePoint | Development
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Michelle-N 18,855 Reputation points Microsoft External Staff Moderator
    2026-06-17T16:50:20.8033333+00:00

    Hi @prolaborate devteam

    Based on your inquiry, I understand that your internal approval teams (such as the Identity Team) require explicit clarification regarding the consent popup displayed during the Prolaborate SharePoint Macro setup. Specifically, you need to verify the exact API calls, Microsoft Graph permissions requested (such as basic profile viewing and data access maintenance), and whether narrower scopes like Sites.Selected can be implemented to avoid broad, tenant-wide access.

    To assist your internal review and approval process, I have broken down the architecture of our consent flow, the exact permissions invoked, and our proposed remediation paths.

    Although the Prolaborate SharePoint web part exclusively communicates with custom Prolaborate backend APIs and does not directly query or extract data from Microsoft Graph, it operates on an On-Behalf-Of (OBO) flow managed by Microsoft Entra ID.

    When a user interacts with the macro, the SharePoint web part requests an access token to communicate securely with the Prolaborate API backend. Entra ID generates a standard consent popup reflecting basic Graph scopes. This visual behavior can cause misunderstandings, as the UI displays generic Microsoft Graph permissions rather than explaining the custom background mechanics.

    -Microsoft Entra ID Permission: User.Read

    Permission Type: Delegated

    Consent UI Display Text: "View your basic profile"

    Technical Purpose in Prolaborate: Used strictly for Authentication and Single Sign-On (SSO). It reads the logged-in user's basic profile (such as UPN or Email) to establish a secure session into Prolaborate. It does not browse or read directory data.

    -Microsoft Entra ID Permission: offline_access

    Permission Type: Delegated

    Consent UI Display Text: "Maintain access to data you have given it access to"

    Technical Purpose in Prolaborate: Used for Session Maintenance. It allows the application to receive a refresh token, which prevents the user from being repeatedly prompted to re-authenticate every time the SharePoint page refreshes.

    -Custom API Scope: access_as_user

    Permission Type: Delegated

    Consent UI Display Text: Configurable Custom Text

    Technical Purpose in Prolaborate: Serves as a Secure API Gateway. It allows the SharePoint web part to securely call the Prolaborate backend services on behalf of the authenticated user.

    Switching from Admin Consent to User Consent was intended to isolate approval to individual active users. However, we acknowledge that within highly secured financial tenants, User Consent is frequently restricted or disabled globally by tenant policies. When user consent is restricted, individual users cannot self-approve these basic scopes, causing the popup to become a workflow bottleneck for security teams who lack deep visibility into what access_as_user entails.

    To provide immediate clarity to your Identity and Compliance teams, we are updating the display text of our custom API scope in the Entra ID App Registration. We recommend updating the description of the access_as_user scope to explicitly state its exact boundaries:

    Updated Scope Description Example:

    "Allows the Prolaborate SharePoint Macro to securely call Prolaborate backend services on behalf of the signed-in user to render architecture models and diagrams. No SharePoint data is read or modified."

    To fully eliminate concerns regarding broad tenant access, I propose two distinct paths moving forward, highly recommended for strict banking compliance:

    -Implementing the Sites.Selected Model

    Instead of relying on broad delegated access, we can transition the integration to utilize the Microsoft Graph Sites.Selected application permission model.

    The Prolaborate App Registration requests Sites.Selected as an Application-level permission. Your SharePoint or Global Administrator grants Admin Consent only once at the tenant level. This permission grants the app zero access by default across the tenant. Your IT security team runs a precise PowerShell script to grant the Prolaborate App ID permissions exclusively to explicit, designated SharePoint Site Collections where the macro is allowed to run. Security benefits include:

    +Completely eliminates tenant-wide visibility.

    +Provides granular, site-by-site control.

    +Easily auditable by your internal compliance teams.

    -Transitioning to a SharePoint Framework (SPFx) Package

    If your organization utilizes modern SharePoint infrastructure, we can transition the deployment to a standard SharePoint Framework (SPFx) web part.

    All required permissions are explicitly declared as plain text inside the package’s structural code configuration file (package-solution.json). When the solution is uploaded to your internal SharePoint App Catalog, it triggers the standard, built-in SharePoint Admin Approval Flow.Security benefits include:

    +Permissions are reviewed and approved directly within the secure SharePoint Admin Center interface.

    +Eliminates external, ambiguous Entra ID consent popups entirely for end-users.

    Please let me know how your Identity team prefers to proceed, or if we can jump on a brief technical call to walk through the architecture diagram together.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".  

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.