Eigene M365 Terms of Use Teil 2: Entra Apps

Table of Contents

Im letzten Teil haben wir die Tenantweit gültigen "Terms of Use" (ToU) gesetzt, in diesem Teil geht es an die Lösungen für Applikationen die mit Entra verbunden werden. Zwar sind Conditional Access ToU oft eine gute Lösung. Doch selbst mit der erforderlichen Entra ID P1-Lizenz stößt man schnell an die Grenzen der 40 möglichen ToU, wenn man für jede Applikation eine eigene Richtlinie definieren möchte.

Werfen wir also einen Blick auf die Optionen, die wirklich für einzelne Applikationen gedacht sind.

Enterprise Applikationen

Enterprise-Applikationen sind, sehr vereinfacht gesagt, die Login-Schnittstellen einer Applikation zu Entra. Wenn hier noch nie Hand angelegt wurde, erlauben ihre Benutzer sehr wahrscheinlich bereits 3rd Party Applikationen Zugriff auf Unternehmensdaten, unter den Terms of Use der Entwickler.

Dieses Genehmigen des Zugangs zu Daten im eigenen Namen nennt sich user consent

Das Bild links dürfte bekannt sein – es zeigt einen solchen Consent Request.

Quelle: Microsoft

Ich gehe an dieser Stelle einfach mal davon aus, dass der Tenant nur Benutzerconsent für eigene Applikationen bzw. unkritische Rechte erlaubt.

⚠️ Achtung: Diese Einstellung ist zwar Empfohlen, aber leider nicht Default! ⚠️

Es ist jedoch wichtig, dass Benutzern der User Consent nicht vollständig verwehrt wird. Sonst gibt es für Applikationen nur eine Bestätigung auf Umgebungsebene durch einen Administrator.

Das wollen wir in diesem Fall vermeiden – stattdessen soll der Benutzer "bewusst" sein Einverständnis geben.

Multi-Tenant Applikationen

Eine Multi-Tenant-Applikation erlaubt es anderen Organisationen, einen ‚Ableger‘ in ihrem Tenant zu installieren und ihre eigenen Benutzerkonten, Berechtigungen und Conditional Access Richtlinien anwenden.

Eine solche Applikation erkennt man im Admin Center in der App Registration daran, dass der abgebildete Button gesetzt ist:

In einer solchen App Registration kann und sollte man unter ‚Branding & Properties‘ die ToU und das Privacy Statement hinterlegen, die den Benutzern im Consent Request angezeigt werden und die sie explizit bestätigen müssen.

⚠️ Achtung: Dies funktioniert ausschließlich bei Multi-Tenant Applikationen! ⚠️

Ich rate dringend davon ab, nur um eigene ToUs pro Applikation hinterlegen zu können, eine Multi-Tenant-Applikation zu erstellen. Es gab bereits in der Vergangenheit erfolgreiche Attacken über den Tenantübergreifenden common-Token-Endpunkt, die nicht funktionierten, wenn die Applikation nur Tokens akzeptierte, die für die eigene Umgebung ausgestellt wurden.

Microsoft empfiehlt ebenfalls Single-Tenant-Applikationen, wo immer möglich.
Hier sind einige Fälle, in denen Multi-Tenant-Applikationen anfällig waren (und teilweise noch, Stand März 2025, sind)::

2023: BingBang – Temporär konnten Benutzer aus beliebigen Tenants auf Azure-Services zugreifen, wenn diese als Multi-Tenant konfiguriert waren.

2023: nOAuth – Emails sind nicht global eindeutig, werden aber von vielen Applikationen zur eindeutigen Authentifizierung genutzt. Allgemeine Fehlimplementierung von OAuth, die sich jedoch auf den eigenen Tenant beschränken lässt und dadurch eine Ausnutzung unwahrscheinlicher macht.

Single-Tenant Applikationen

In Single-Tenant-Applikationen gibt es nur die Möglichkeit, den Consent für die Rechte einzuholen, es wird fairerweise davon ausgegangen, dass innerhalb des eigenen Tenants bereits bekannte Terms of Use und Privacy Regeln gelten.

Bei einer Single-Tenant-Applikation ist der Text im Consent Request immer folgender:

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.

Erweiterte Consent Features und Informationen

Dieses Kapitel war auf einer sehr, SEHR hohen Flughöhe, damit der Fokus auf der ToU-Ebene bleibt.

Wer Appetit bekommen hat, sich mehr mit Enterprise-Apps und OAuth-Grants zu beschäftigen, dem empfehle ich folgende Themen, in absteigender Wichtigkeit und steigender Komplexität:

CIAM Systeme

Dies ist eher eine Honorable Mention, wenn alle Stricke reißen, und etwas Eigenes entwickelt werden muss.

Customer bzw. Consumer Identity And Access Management Systeme sind stark vereinfachte Identitätsprovider, die für sehr hohe Benutzerzahlen und maximale Flexibilität ausgelegt sind. Dabei müssen fast alle Abläufe selbst entwickelt oder zumindest umfangreich angepasst werden.

Bei der Interaktion mit vielen externen Benutzern, kann es sich auf mehreren Ebenen lohnen, ein solches System zu etablieren. Dadurch lassen sich teure Voll-Lizenzen einsparen, erweiterte oder angepasste Informationen abrufen sowie eine klare Trennung zwischen externen und internen Benutzern schaffen.

Dafür ist die initiale Investition erheblich höher und kann nicht von Administratoren allein gestemmt werden, sondern erfordert professionelle Entwickler.

Stand März 2025 besteht das Microsoft-Angebot aus Entra External ID, das jedoch noch in den Kinderschuhen steckt, und dem ‚soft‘ abgekündigten Vorgänger Entra ID (bzw. Azure AD) B2C.

Zusammenfassung

Unsere neuen Optionen lassen sich wie folgt zusammenfassen:

Einstellung	Betroffene Benutzertypen	Sichtbarkeit	Explizite Bestätigung	"Dateityp"
OAuth Consent	Interne Benutzer, Gäste	Erstmalige Authentifizierung an einer Applikation *	✅ Erforderlich *	Angeforderte Einzelrechte (Scopes)
Multi-Tenant Enterprise App	Intern, Gäste	Erstmalige Auth *	✅ Erforderlich *	URL
Single-Tenant Enterprise App	Intern, Gäste	Erstmalige Auth *	✅ Erforderlich *	Es sind nur die OAuth-Rechte sichtbar!
CIAM System	Registrierte Benutzer	Bei Registrierung, Login **	✅ Erforderlich **	Beliebig **

Vorausgesetzt es wurde kein Admin Consent gegeben*
* Je nachdem, wie die entwickelte Lösung aussieht.*

Ich habe es bereits im ersten Teil erwähnt, aber es ist wichtig, es noch einmal zu betonen: Wenn in einer Applikation kein Login erforderlich ist (Anonyme Nutzer), greifen natürlich auch keine der hier aufgeführten Konfigurationen.

Im (geplant) letzten Teil dieser Serie werde ich auf Optionen in Microsoft Teams eingehen, und Lösungen in anderen M365 Applikationen ansprechen.

Wenn es etwas gibt, das Sie kennen und ich aufnehmen könnte oder sie besonders interessiert, schreiben Sie es in die Kommentare oder vernetzen Sie sich mit mir auf LinkedIn!