Die entscheidende Frage
Handelt deine Anwendung im Auftrag eines angemeldeten Benutzers oder eigenständig als Dienst? Microsoft Graph unterscheidet dafür Delegated Permissions und Application Permissions. Ein nächtlicher Job ohne Benutzeranmeldung hat andere Anforderungen als ein interaktives Werkzeug.
| Eigenschaft | Delegated | Application |
|---|---|---|
| Identität | Anwendung mit Benutzerkontext | Anwendung ohne Benutzerkontext |
| Typischer Ablauf | Interaktive Anmeldung | Client Credentials |
| Zugriff | Durch App-Berechtigung und Benutzerzugriff begrenzt | Durch zugewiesene App-Rechte und Ressourcenregeln begrenzt |
| Zustimmung | Abhängig von Recht und Tenant-Richtlinie | Admin Consent erforderlich |
| Token-Claim | Typischerweise scp |
Bei Graph-App-Berechtigungen typischerweise roles |
Die Tabelle ist eine Orientierung. Eine API kann zusätzlich Rollen, Lizenzen oder spezielle Ressourcenkonfigurationen voraussetzen.
Delegated: mit Benutzerkontext
Ein interaktives Profilwerkzeug kann /me verwenden. Für das Lesen des eigenen Profils ist User.Read ein typischer Einstieg. Zustimmung zu einem Scope gibt einer Anwendung nicht automatisch Zugriff auf alles, was ein Administrator im Portal sehen kann.
Ein Benutzer mit hohen Rollen macht einen beliebigen Graph-Aufruf also nicht automatisch erfolgreich. Umgekehrt ersetzt eine breite delegierte Berechtigung keine fehlende Benutzerberechtigung. Prüfe immer die konkrete API-Methode und die benötigten Eigenschaften.
Application: eigenständiger Dienst
Ein App-only-Job besitzt keinen angemeldeten Benutzer. /me passt dazu nicht; der Job muss beispielsweise /users/{id} adressieren. Die gleiche Berechtigungsbezeichnung kann in beiden Modellen existieren und trotzdem einen anderen Wirkungsbereich haben.
Ein gutes Beispiel ist Mail.Send: Delegiert geht es um Versand im Benutzerkontext. Als Application Permission kann sie ohne passende zusätzliche Begrenzung weitreichenden Postfachzugriff ermöglichen. Für produktive Dienste gehören Ressourcenbegrenzung, Identitätsschutz und Überwachung zum Entwurf.
Rechte methodisch auswählen
- Lege Methode und Endpunkt fest, nicht nur das grobe Projektziel.
- Entscheide, ob ein Benutzer vorhanden ist.
- Öffne die Berechtigungstabelle der jeweiligen API-Dokumentation.
- Starte mit der dort genannten geringsten passenden Berechtigung.
- Prüfe Benutzerrollen, Ressourcenumfang und Zustimmung separat.
- Teste sowohl erlaubte als auch ausdrücklich nicht erlaubte Zugriffe.
Für erste Einordnungen bietet der PATCHWERK Permission Helper einige konkrete Szenarien. Er ersetzt nicht die Methodendokumentation.
Häufige Fehler eingrenzen
401 Unauthorized: Prüfe, ob ein gültiges Access Token für Microsoft Graph verwendet wird. Ein ID Token ist kein Ersatz. Ablaufzeit und Audience müssen passen.
403 Forbidden: Prüfe Scopes bzw. Rollen, erteilte Zustimmung, Benutzerrechte und zusätzliche Ressourcenrichtlinien. Nur weitere Rechte hinzuzufügen verdeckt häufig die eigentliche Ursache.
App-only mit /me: Der Endpunkt setzt einen Benutzer voraus. Verwende einen für App-only unterstützten Endpunkt und passende Application Permissions.
Recht konfiguriert, Zugriff fehlt: Die Registrierung allein erteilt noch keine Zustimmung. Nach einer Berechtigungsänderung ein neues Token anfordern und dessen tatsächliche Claims kontrollieren.
Tokens sind Zugangsdaten. Für die Prüfung keine produktiven Tokens in öffentliche Decoder oder fremde Tools kopieren. Client Secrets nicht in Skripte oder Git einchecken. Bevorzuge für Dienste Zertifikate oder geeignete Workload-Identitäten.