Delegated permissions und Application permissions

In Microsoft 365 Enterprise Applications (z. B. Azure AD App Registrations) unterscheidet man grundsätzlich zwei Modelle, wie eine App auf Daten und APIs zugreift:

1. Delegierte Berechtigungen

“Your application needs to access the API as the signed-in user.”

• Was heißt das?
  Die App „übernimmt“ die Identität des aktuell angemeldeten Benutzers. Sie kann nur auf die Ressourcen und Daten zugreifen, für die dieser Benutzer selbst auch Rechte hat.
• Wann verwendet man das?
  Wenn die App interaktiv ist – also z. B. eine Web- oder Desktop-App mit Benutzeranmeldung, oder eine Single-Page-App (SPA) in JavaScript.
• Genehmigung:
  Bei der ersten Ausführung autorisiert der Benutzer selbst (oder ein Administrator im Namen aller Nutzer) die gewünschten Berechtigungen.
• Beispiele für häufige delegated Permissions:
  • User.Read
    Liest Profil­informationen des angemeldeten Nutzers (Vorname, Nachname, E-Mail)
  • Mail.Read
    Ermöglicht der App, die E-Mails des aktuell angemeldeten Nutzers zu lesen
  • Calendars.ReadWrite
    Erlaubt der App, Termine im Kalender des Nutzers anzulegen oder zu ändern

Szenario-Beispiel:
Eine webbasierte CRM-Applikation zeigt Ihrem Vertriebs­mitarbeiter dessen Outlook-Termine und E-Mails an, damit er direkt aus dem CRM heraus Nachrichten beantworten oder Besprechungen planen kann. Die App nutzt dafür die delegated Berechtigungen Mail.Read und Calendars.ReadWrite.

2. Anwendungs- (Application-) Berechtigungen

“Your application runs as a background service or daemon without a signed-in user.”

• Was heißt das?
  Die App erhält eine “Eigenständige” Identität (Client-Credentials) und kann im Hintergrund – völlig unabhängig von einem interaktiven User-Login – auf Ressourcen zugreifen.
• Wann verwendet man das?
  Für serverseitige Dienste, automatisierte Batch-Jobs oder Daemon-Prozesse, die ohne Benutzer­interaktion laufen müssen.
• Genehmigung:
  Ein globaler Administrator muss die App einmalig autorisieren, da hier im Prinzip “höchstmögliche” Rechte vergeben werden.
• Beispiele für typische application Permissions:
  • Mail.Read.All
    Liest alle Postfächer in der Organisation (z. B. für Compliance-Scans)
  • User.Read.All
    Liest Profile aller Benutzer in der Tenant-Directory (z. B. für eine Benutzer­verzeichnis-Synchronisation)
  • Group.ReadWrite.All
    Erlaubt Erstellen, Ändern oder Löschen von Gruppen in der gesamten Organisation

Szenario-Beispiel:
Ein nächtlicher Synchronisationsdienst durchsucht alle Exchange-Postfächer nach bestimmten Schlüsselwörtern und archiviert automatisiert alte E-Mails. Dieser Dienst verwendet application Berechtigungen wie Mail.Read.All, weil kein einzelner Benutzer angemeldet ist und auf alle Postfächer zugegriffen werden muss.

Zusammenfassung in der Übersicht

Wichtige Hinweise:

1. Least-Privilege-Prinzip: Gib der App nur die minimal notwendigen Berechtigungen.
2. Admin-Consent: Application-Berechtigungen erfordern immer Admin-Zustimmung.
3. Token-Acquisition:
   • Delegated: OAuth 2.0 Authorization Code Flow (mit Benutzer-Signin)
   • Application: OAuth 2.0 Client Credentials Flow