Custom M365 Terms of Use Part 2: Entra Apps

In the last part, 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.

Or you also encountered the issues in non-persistent VDI environments and are looking for options.

So let’s take a look at the options that are truly intended for individual applications.

Enterprise Applications

I will assume at this point that the tenant only allows user consent for its own applications or non-critical permissions.

⚠️ Warning: While this setting is recommended, it is unfortunately not the default! ⚠️

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.

We want to avoid that in this case — instead, the user should "consciously" give their consent.

---

Multi-Tenant Applications

A multi-tenant application allows other organizations to install an ‘instance’ in their tenant and apply their own user accounts, permissions, and Conditional Access policies.

You can identify such an application in the Admin Center by looking at the App Registration and check whether the following button is set:

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.

⚠️ Warning: This only works for multi-tenant applications! ⚠️

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

Microsoft also recommends using single-tenant applications whenever possible.
Here are some cases where multi-tenant applications have been vulnerable (and, as of March 2025, some still apply):

• 2023: BingBang – Users from any tenant could temporarily access Azure services when those were configured as multi-tenant.
• 2023: nOAuth – Emails are not globally unique, yet many applications rely on them for authentication. This is a common OAuth misimplementation, where reducing logins to a single tenant significantly reduces the risk of exploitation.

---

Single-Tenant Applications

In single-tenant applications, the only option is to obtain consent for OAuth permissions. It is assumed, fairly, that well-known Terms of Use and Privacy policies already apply within the tenant.

For a single-tenant application, the text in the consent request always appears as follows:

Accepting these permissions means that you allow this app to use your data as specified in their terms of service and privacy statement. You can change these permissions at https://myapps.microsoft.com.


Only accept if you trust the publisher and if you selected this app from a store or website you trust. Ask your admin if you’re not sure. Microsoft is not involved in licensing this app to you.

---

Advanced Consent Features and Further Information

This chapter was intentionally kept at a very high level, to focus primarily on the ToU aspect.

If you’re interested in diving deeper into Enterprise Apps and OAuth Grants, I recommend the following topics, listed in order of decreasing priority but increasing complexity:

1. The OAuth consent screen for users and what it entails
2. How OAuth consent can be exploited
3. Restricting user consent
4. Configuring the admin request process
5. Granular consent policies by Pim Widdershoven
6. Granular consent policies — detailed Microsoft documentation

---

CIAM Systems

This is more of an honorable mention — a last resort if everything else fails and a custom solution needs to be developed.

Customer or Consumer Identity and Access Management (CIAM) systems are highly simplified identity providers designed for very high user numbers and maximum flexibility. However, nearly all processes must be custom-developed or at least extensively adapted.

When interacting with large numbers of external users, implementing such a system can be beneficial on multiple levels. It allows organizations to:

• Reduce costs by saving on expensive full licenses,
• Retrieve extended or customized user information, and
• Establish a clear separation between external and internal users.

However, the initial investment is significantly higher and cannot be handled by administrators alone — it requires professional developers.

As of March 2025, Microsoft’s offering consists of Entra External ID, which is still in its early stages, and its ‘soft’ deprecated predecessor, Entra ID (formerly Azure AD) B2C.

---

Summary

Our new options can be summarized as follows:

Setting	Affected User Types	Visibility	Explicit Confirmation	"File Type"
OAuth Consent	Internal users, guests	First authentication to an application *	✅ Required *	Requested individual permissions (scopes)
Multi-Tenant Enterprise App	Internal users, guests	First auth *	✅ Required *	URL
Single-Tenant Enterprise App	Internal users, guests	First auth *	✅ Required *	Only OAuth permissions are visible!
CIAM System	Registered users	During registration, login **	✅ Required **	Arbitrary **

* Assuming no Admin Consent was granted.
** Depending on the design of the custom solution.

I already mentioned this in Part 1, but it’s important to emphasize again:
If an application does not require login (anonymous users), none of the configurations listed here will apply.

In the (planned) final part of this series, I will discuss options in Microsoft Teams and explore solutions in other M365 applications.

If there’s anything you know that I could include, or if there’s a topic that particularly interests you, feel free to leave a comment or connect with me on LinkedIn!