{"id":948,"date":"2025-03-03T19:33:27","date_gmt":"2025-03-03T18:33:27","guid":{"rendered":"https:\/\/sparrow365.de\/?p=948"},"modified":"2025-04-20T22:53:16","modified_gmt":"2025-04-20T20:53:16","slug":"custom-m365-terms-of-use-part-2-entra-apps","status":"publish","type":"post","link":"https:\/\/sparrow365.de\/index.php\/en\/2025\/03\/03\/custom-m365-terms-of-use-part-2-entra-apps\/","title":{"rendered":"Custom M365 Terms of Use Part 2: Entra Apps"},"content":{"rendered":"

In the last part<\/a>, we set the tenant-wide "Terms of Use" (ToU). In this part, we will look at solutions for applications connected to Entra. While Conditional Access ToU is often a good solution, even with the required Entra ID P1 license, you will quickly reach the limit of 40 possible ToUs if you define a separate policy for each application.<\/p>\n

\"TenantLimitations\"<\/a><\/p>\n

Or you also encountered the issues in non-persistent VDI environments and are looking for options.<\/p>\n

So let’s take a look at the options that are truly intended for individual applications.<\/p>\n


<\/p>\n

Enterprise Applications<\/h2>\n
\n <\/p>\n

Enterprise applications are, simply put, the login interfaces of an application to Entra. If no adjustments have been made here, your users are most likely already allowing third-party applications to access company data under the Terms of Use set by the developers.

This granting of access to data on one’s behalf is called user consent<\/b>.

The image on the left should be familiar\u2014it shows such a consent request.
Source: Microsoft<\/a> <\/p>\n<\/div>\n


<\/p>\n

I will assume at this point that the tenant only allows user consent for its own applications or non-critical permissions.<\/p>\n

\"AdminCenterRestrictionOnUserConsent\"<\/p>\n

\n

\u26a0\ufe0f Warning: While this setting is recommended, it is unfortunately not the default!<\/a><\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n


<\/p>\n

However, it is important that users are not entirely denied the ability to provide user consent. Otherwise, applications would only receive approval at the Tenant level from an administrator.<\/p>\n

We want to avoid that in this case \u2014 instead, the user<\/strong> should "consciously" give their consent.<\/p>\n


<\/p>\n

\n

Multi-Tenant Applications<\/h3>\n

A multi-tenant application allows other organizations to install an \u2018instance\u2019 in their tenant and apply their own user accounts, permissions, and Conditional Access policies.<\/p>\n

You can identify such an application in the Admin Center by looking at the App Registration<\/strong> and check whether the following button is set:<\/p>\n

\"AdminCenterAPI\"<\/p>\n

In such an app registration, you can and should define the Terms of Use (ToU) and Privacy Statement under ‚Branding & Properties‘. These will be displayed in the consent request and must be explicitly accepted by users.<\/p>\n\n\n\n\n\n
<\/th>\n<\/th>\n<\/tr>\n<\/thead>\n
\"TermsOfUseInAdminCenter\"<\/td>\n\"EntraID<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n

\u26a0\ufe0f Warning: This only works for multi-tenant applications!<\/em> \u26a0\ufe0f<\/p>\n<\/blockquote>\n

I strongly advise against<\/strong> creating a multi-tenant application solely<\/em> to set individual ToUs per application. In the past, successful attacks have exploited the cross-tenant common<\/code> token endpoint, which would not have worked if the application only accepted tokens issued for its own environment.<\/p>\n

\n

Microsoft also recommends using single-tenant applications whenever possible.<\/a><\/strong>
\nHere are some cases where multi-tenant applications have been vulnerable (and, as of March 2025, some still apply<\/strong>):<\/p>\n