The new version of the Jint Configurator is based on a single Entra ID application, Jint Intranet, which is gradually replacing the applications dedicated to each module. This article explains which permissions are requested, when and why they are requested, and what this model guarantees for the security of your Microsoft 365 tenant.

Contents

1. What's changing: a single application
2. The two Configurator versions coexist
3. Delegated permissions: the principle and its guarantees
4. Permissions requested at sign-in
5. Permissions on your SharePoint resource
6. Understanding AllSites.FullControl
7. What Jint does not do or store
8. Approving permission requests
9. Frequently asked questions

1. What's changing: a single application

Historically, each Jint functional component had its own application registration in Entra ID (Jint Configurator, Jint Administration, Jint Site Engine, Jint Contribution Center, and so on). Each new module therefore meant a new application for your IT department to identify, approve, and monitor.

We are unifying this model. The Configurator's features are converging into a single application: Jint Intranet.

What this means for you:

• A single point of control. A single application registration, a single consent screen to audit, and a single entry in your Enterprise applications for revoking access if you choose.
• This is not one more application; it is the last one. The permissions requested here are not added to a growing stack; they replace it. In time, the applications for each module will disappear.
• Future requests will be occasional, and there will be no new application (Entra ID). When a feature needs an additional permission, it will request it when you use the feature, through this same application. You will no longer see a Jint application appear “alongside” it.

This choice follows Microsoft's identity platform principle of incremental consent: rather than requesting everything on day one “just in case,” the application requests a permission only when the relevant feature actually needs it.

2. The two Configurator versions coexist

You are not required to grant these permissions immediately in order to continue working.

The old Configurator and the new Configurator operate in parallel, with the same configuration data until December 1, 2026. You can therefore choose your own pace:

• You approve the permissions: your administrators can access the new Configurator and its features through the single Jint Intranet application.
• You do not approve them yet: the old Configurator remains fully operational with the permissions already in place until December 1, 2026. Your intranet and end users are not affected until then.

Nothing will be interrupted or lost before this deadline: your existing configuration remains the same, regardless of which version you use. This gives you time to have the new scope approved by your IT department or security committee and plan the transition before December 1, 2026.

3. Delegated permissions: the principle and its guarantees

All permissions described in this article are delegated. The application always acts on behalf of the signed-in user and can never exceed what that user is authorized to do themselves.

• Jint cannot do anything unless a user is authenticated.
• The access scope is exactly that of the signed-in user: no more and no less.
• A user with read-only access to a site remains read-only through Jint.
• A disabled or restricted account cannot use Jint to bypass these restrictions.
• Your Conditional Access policies and tenant controls apply in full.
• No privilege escalation is possible, in accordance with the OAuth 2.0 standard implemented by the Microsoft Identity Platform.

For more information, see: Overview of Microsoft Graph permissions and Scopes and permissions in the Microsoft identity platform.

4. Permissions requested at sign-in

These two permissions are requested only once, when each user signs in to the Configurator for the first time. They provide the minimum foundation required to open a session.

5. Permissions on your SharePoint resource

Some actions do not go through Microsoft Graph but directly through your SharePoint resource (https://<your-tenant>.sharepoint.com).

6. Understanding AllSites.FullControl

This name may initially seem concerning. It deserves a precise explanation.

In a delegated context, AllSites.FullControl does not give the application total, autonomous control over your SharePoint sites. It authorizes the application to perform, on behalf of the signed-in user, the actions that user could already perform themselves in the SharePoint interface. The limit is always defined by the user's permissions.

In other words:

• A user without administrative rights on a site will not be able to perform administrative actions there through Jint.
• A user whose account is disabled or restricted will not be able to use Jint to bypass these restrictions.
• Your Conditional Access policies apply without exception.

Why is this scope necessary? Enabling the Unified Experience on a site or applying a template with the Site Factory requires writing custom actions at the site level and working across multiple site collections. Delegated mode allows these features to operate across all sites the user already has access to, without requiring approval on a site-by-site basis.

7. What Jint does not do or store

• No application permissions. The Configurator uses only delegated permissions. It therefore can never act outside a user session. (The only exception in the Jint ecosystem, documented separately, is the Mozzaik365 Deployment application, limited to the site(s) hosting the SharePoint application catalog(s), for package deployment.)
• No content or personal data storage on our servers. The Configurator reads information from your Microsoft 365 services at the time it is displayed, through the secure Microsoft Graph and SharePoint APIs.
• No access to your email, files, or calendars within the scope described here. The Configurator is a configuration tool: it manages settings, audiences, and site references.
• The only data retained consists of anonymized and aggregated configuration and usage data, transmitted through a secure connection to a dedicated Azure workspace hosted in a Microsoft-certified data center. It is used exclusively for performance analysis and service improvement. It is never used for advertising purposes or shared with third parties.

8. Approving permission requests

There are two scenarios, depending on the type of permission.

a. Administrator consent for the Jint Intranet application

Entra ID administrator consent is required to deploy the application across your organization. This is done once, on the consent screen displayed when an administrator signs in for the first time, or from the Microsoft Entra admin center (Enterprise applications > Jint Intranet > Permissions).

If your tenant allows user consent, the incremental scopes described in section 4 can be granted individually by each user. If user consent is disabled, an administrator can approve them once for the entire organization.

b. Permissions approved on the SharePoint side

The permissions used by Jint's SharePoint components are approved from the SharePoint admin center:

1. In the Microsoft 365 admin center, under Admin centers, select SharePoint.
2. In the menu, open Advanced management, then API management.
3. Select the pending requests from the Jint solution one by one and approve them.

Microsoft documentation: Connect to Azure AD-secured APIs in SharePoint

9. Frequently asked questions

Why are new permissions appearing even though I already use Jint?

Because we are consolidating into a single application what was previously spread across several applications. The request you see consolidates access that was already granted elsewhere. This is a simplification operation, not an expansion of scope.

Will I have to approve a new Jint application for each module?

No. That is precisely the purpose of this change. Future needs will result in occasional scope requests on the Jint Intranet application, never in a new application registration.

Can I continue using the old Configurator?

Yes, until December 1, 2026. The two versions coexist until that date and share the same configuration. As long as the permissions have not been granted, the old Configurator will continue to work normally, with no impact on your end users. After December 1, 2026, only the new Configurator will remain available, so it is best to plan ahead and validate the permissions with your IT department before that date.

Can I refuse a permission?

Yes. Because consent is incremental, refusing a scope disables the feature that depends on it without blocking the rest of the Configurator.

How do I revoke access?

From the Microsoft Entra admin center: Enterprise applications > Jint Intranet > Permissions, or by deleting the enterprise application. Access is cut off immediately.

Do these permissions give Jint access to data that my users cannot access?

No. In delegated mode, this is structurally impossible: each call is executed with the signed-in user's token and is subject to exactly the same access controls as the user.

Have a question about the exact permission scope in your environment? Contact Jint Support; we will be happy to provide your IT department with details for each feature.