The Jint solution is an extension of SharePoint Online that offers, through various features, simplified access to information from the Microsoft 365 services in your environment. This access is done via APIs secured by Entra ID, which requires certain permissions to be granted on your tenant.
This article explains the nature of these permissions, the security guarantees they imply, and the procedure to approve them.
Table of Contents
- Delegated Permissions vs Application Permissions
- Why Jint Uses Almost Exclusively Delegated Permissions
- Summary of Permissions by Jint Application
- Table of Microsoft Graph and Jint API Permissions by Component
- Managing Permission Requests
1. Delegated Permissions vs Application Permissions
In the Microsoft 365 security model, two types of permissions exist for applications registered in Entra ID:
- Delegated permissions (Delegated permissions): the application acts on behalf of a signed-in user. It can never do more than what that user is authorized to do themselves.
- Application permissions (Application permissions): the application acts autonomously, without a signed-in user, with an access level defined independently of individual user rights.
Jint uses delegated permissions for all of its applications, except for Mozzaik365 Deployment, which has a limited-scope application permission described in section 4.
2. Why Jint Uses Almost Exclusively Delegated Permissions
This design choice is fundamental for the security of your environment. Specifically, this means that:
- Jint can never act without a user being authenticated.
- The application inherits exactly the access scope of the signed-in user — no more, no less.
- If a user has read-only access to a site, Jint will also have read-only access.
- If a user is not authorized to publish content, Jint cannot publish content on their behalf.
- Jint cannot escalate privileges or bypass access policies defined in Microsoft 365.
All permissions are subject to explicit consent from an Entra ID administrator, in accordance with the OAuth 2.0 standard implemented by the Microsoft Identity Platform.
Exception: Mozzaik365 Deployment
Mozzaik365 Deployment is the only Jint application with an application permission. This permission (Sites.Selected) is strictly limited to the site(s) containing the SharePoint application catalog(s). Its sole function is to allow Jint to deploy and update the SharePoint packages of the solution.
3. Summary of Permissions by Jint Application
| Entra ID Application | Permission Type | Requested Permissions |
|---|---|---|
| Mozzaik365 Deployment | Application |
SharePoint Sites.Selected (site(s) containing the application catalog(s) only) |
| Jint Configurator | Delegated |
User.Read, GroupMember.Read.All
|
| Jint Administration | Delegated |
User.Read, SharePoint AllSites.FullControl
|
| Jint Site Engine | Delegated |
User.Read, SharePoint AllSites.FullControl, SharePoint TermStores.Read.All
|
| Jint Contribution Center | Delegated |
User.Read, SharePoint AllSites.FullControl
|
Understanding AllSites.FullControl
Some Jint applications request the permission SharePoint > AllSites.FullControl. This name may sound concerning; it deserves a precise explanation.
In the context of delegated permissions, this permission does not grant the application full and autonomous control over all SharePoint sites. It means the application is authorized to perform, on behalf of the signed-in user, the same actions that user could perform directly in the SharePoint interface. The application can never exceed the rights of the signed-in user.
In other words:
- A user without administrative rights on a site cannot, via Jint, perform administrative actions on that site.
- A user whose account has been disabled or restricted cannot use Jint to bypass those restrictions.
- Conditional access policies and controls defined in your Microsoft 365 tenant apply fully.
Why is this extended permission necessary?
Features like the Site Factory (duplication and creation of SharePoint spaces from a template) or the Contribution Center (publishing content on various sites) require interaction with multiple site collections. The AllSites.FullControl permission in delegated mode allows these features to operate on all sites the user has access to, without needing site-by-site approval.
4. Table of Microsoft Graph and Jint API Permissions by Component
These permissions are approved from the SharePoint Admin Center > API Management. They allow Jint components to call Microsoft Graph APIs and Jint APIs on behalf of the signed-in user.
| API Name | Permissions | Components Using the Permission |
|---|---|---|
| Microsoft Graph | User.Read.All | Teams, Directory, Newcomers, Professional Birthdays, My Summary, Organization Chart |
| Microsoft Graph | Group.Read.All | Teams, Site Directory, My Applications, Directory, Newcomers, Professional Birthdays |
| Microsoft Graph | ChannelMessage.Send | Teams, Contribution Center |
| Microsoft Graph | Sites.Read.All | Site Directory, My Events, My Documents, Search Results |
| Microsoft Graph | Mail.Read | My Emails, My Summary |
| Microsoft Graph | Calendars.Read | My Meetings, My Summary |
| Microsoft Graph | Calendars.ReadWrite | My Meetings |
| Microsoft Graph | Tasks.ReadWrite | My Tasks, My Summary |
| Microsoft Graph | Team.ReadBasic.All | Contribution Center |
|
Mozzaik365 Contribution Center
|
Access_as_user | Contribution Center |
5. Managing Permission Requests
To grant the necessary permissions for the Jint solution to function, please follow the steps below:
- In the Office 365 Admin Center, under the Admin centers group, select SharePoint.
- To view pending permission requests, in the SharePoint modern Admin Center menu, select the link Manage WebApiPermission.
- Click on API Management.
- Select, one by one, the permission requests for the Jint solution and approve them.
Comments
0 comments
Please sign in to leave a comment.