Jetzt bauen

Microsoft Graph OAuth: Outlook- und Microsoft 365-Postfächer authentifizieren (Leitfaden 2026)

Microsoft Graph OAuth 2026

Microsoft Graph OAuthOutlook- und Microsoft 365-Postfächer authentifizieren

Ein vollständiger Leitfaden für Microsoft Graph OAuth im Jahr 2026 für SaaS-Entwickler. Behandelt Microsoft Entra App-Registrierung, Authority-Endpunkte, Mail-Bereiche (Scopes), delegierte vs. Anwendungsberechtigungen, Admin-Zustimmung, Auth-Code + PKCE, Refresh-Token-Rotation, AADSTS-Fehlercodes und wie Unipile 5 Wochen OAuth-Plumbing in 5 Minuten eliminiert.

Bauen Sie es mit Unipile MS Graph Leitfaden
link_outlook_account.py
import Anfragen # Schritt 1: Einen gehosteten Authentifizierungslink generieren response = requests.Beitrag( "https://apiXXX.unipile.com:XXX /api/v1/gehostete/konten/verknüpfen", Kopfzeilen={"X-API-KEY": api_key}, json={ "Typ": "erstellen", "Anbieter": ["MICROSOFT"], "api_url": ihr_dsn, "giltBis": "2026-12-31T23:59:59Z" } ) # Schritt 2: Leiten Sie den Benutzer auf die URL weiter auth_url = response.json()["url"] # Unipile übernimmt den gesamten OAuth-Ablauf # inkl. Entra, Scopes, Tokens, Aktualisierung
Microsoft OAuth verarbeitet. Postfach bereit.
2026 Kontext

Warum Microsoft Graph OAuth im Jahr 2026 nicht verhandelbar ist

Wenn Ihre SaaS-Anwendung E-Mails von Outlook oder Microsoft 365 liest, sendet oder synchronisiert, ist Microsoft Graph OAuth nicht mehr optional. Drei wichtige Deprekationen haben Basic Auth, Legacy-Protokolle und App-Passwörter obsolet gemacht. OAuth 2.0 über die Microsoft Graph API ist der einzig unterstützte Weg.

Basic Auth - Vollständig veraltet
Microsoft hat die Basisauthentifizierung für Exchange Online im Oktober 2022 deaktiviert. Dies betrifft IMAP, POP3, SMTP, EWS, MAPI, OAB, Outlook Anywhere und RPC über HTTP. Es gibt keine Ausnahmen und keine Möglichkeiten für Fristverlängerungen mehr.
Deaktiviert Okt. 2022
EWS - Sonnenuntergangs-Zeitplan
Exchange Web Services (EWS) befindet sich im Wartungsmodus. Microsoft hat keine neuen Funktionen angekündigt und empfiehlt die Migration zu Microsoft Graph. Obwohl es noch nicht vollständig eingestellt ist, wird die Erstellung neuer Integrationen auf EWS im Jahr 2026 zu einer technischen Schuld führen, die Sie bereuen werden.
Wartungsmodus
OAuth 2.0 – Der erforderliche Standard
Microsoft Graph OAuth über Microsoft Entra ID (früher Azure AD) ist die einzige offiziell unterstützte Authentifizierungsmethode für produktive SaaS-Anwendungen, die 2026 auf Outlook- und Microsoft 365-Mailboxen zugreifen. Diese Anleitung behandelt die vollständige Implementierung.
Erforderlicher Standard
Was Microsoft Graph OAuth ermöglicht
Outlook-Postfächer im Namen authentifizierter Benutzer lesen, senden und synchronisieren
Greifen Sie mit einer einzigen App-Registrierung auf Microsoft 365 und persönliche Outlook.com-Postfächer zu
Langlebige Aktualisierungstoken mit automatischer Rotation (keine Neuauthentifizierung für aktive Benutzer)
Granulare Umfangskontrolle: Fordern Sie nur die Berechtigungen an, die Ihre App tatsächlich benötigt
Multi-Tenant-Unterstützung: Eine App-Registrierung dient allen Kundentennants
Einhaltung von Unternehmensrichtlinien für bedingten Zugriff und MFA
OAuth-Flows

Die 3 OAuth-Flows, die Microsoft unterstützt (und welchen eine SaaS-Anwendung benötigt)

Die Identitätsplattform von Microsoft unterstützt mehrere OAuth 2.0-Grant-Typen. Die Wahl des falschen Typs ist eine häufige Ursache für verschwendete Ingenieurszeit. Hier finden Sie die Aufschlüsselung für SaaS-Anwendungen, die im Namen ihrer Benutzer auf E-Mails zugreifen.

Empfohlen für SaaS
Autorisierungs-Code + PKCE
RFC 6749 Abschnitt 4.1 + RFC 7636
Der Benutzer wird zur Anmeldeseite von Microsoft weitergeleitet, authentifiziert sich und erteilt die Zustimmung. Ihre App tauscht den zurückgegebenen Autorisierungscode gegen Zugriffs- und Aktualisierungstoken aus. PKCE (Proof Key for Code Exchange) verhindert Angriffe durch Code-Abfangen und ist für öffentliche Clients obligatorisch und für alle Clients im Jahr 2026 empfohlen.
Verwenden Sie dies für SaaS-Anwendungen, die auf Benutzer-Mailboxen zugreifen
Client-Anmeldeinformationen
OAuth 2.0 Abschnitt 4.4 (nur App)
Keine Benutzerinteraktion. Ihre Anwendung authentifiziert sich als sie selbst anhand einer Client-ID und eines Geheimnisses (oder Zertifikats). Erfordert Anwendungsberechtigungen (nicht delegierte), was bedeutet, dass ein Mandantenadministrator die Zustimmung zum Zugriff auf alle Postfächer in der Organisation erteilen muss. Kein Bildschirm für Benutzerzustimmung.
Nur für interne Tools mit Administratorzugriff
Gerätecodefluss
OAuth 2.0 Geräteautorisierungsübertragung
Entwickelt für Geräte ohne Browser (CLIs, IoT, Smart-TVs). Der Nutzer besucht eine URL auf einem anderen Gerät zur Authentifizierung. Nicht relevant für webbasierte SaaS-Anwendungen, bei denen eine Weiterleitung möglich ist.
Nicht anwendbar auf Standard-SaaS-Webanwendungen
Beginnen Sie mit dem Aufbau Ihres Microsoft OAuth-Flows
Unipile - Microsoft Entra App-Registrierung
Schritt-für-Schritt-Einrichtung

Microsoft Entra Anwendungsregistrierung: 7 Schritte

Bevor Ihre Anwendung OAuth-Token anfordern kann, benötigen Sie eine registrierte Anwendung in Microsoft Entra ID (früher Azure Active Directory). Hier sind die genauen Schritte, einschließlich der relevanten Feldwerte und der kosmetischen.

1
Eine App-Registrierung im Azure-Portal erstellen
Navigieren zu portal.azure.com, geh zu Microsoft Entra ID (in der oberen Leiste suchen), dann App-Registrierungen, dann klicken + Neue Registrierung. Siehe die Vollständige Microsoft OAuth-Dokumentation für weitere Informationen.
Name
Ihr App-Name. Das ist es, was Benutzer auf dem Microsoft-Zustimmungsbildschirm sehen. Verwenden Sie Ihren Produktnamen, keine technische Kennung.
Unterstützte Kontotypen
Für eine Multi-Tenant-SaaS, die sowohl Geschäfts- als auch Privatnutzer bedient: auswählen Konten in einem beliebigen Verzeichnis einer Organisation (beliebiger Microsoft Entra ID Mandant – Mandantenübergreifend) und persönliche Microsoft-Konten. Dies entspricht dem /gemeinsam Autorisierungsendpunkt.
Tipp: Wenn Sie nur Microsoft 365-Geschäftskonten bedienen (keine persönlichen Outlook.com-Konten), wählen Sie nur "Mandantenübergreifend" aus. Dies verwendet die /Organisationen und reduziert Ihre Angriffsoberfläche. Mehr über Autorität Endpunkte in Abschnitt 4.
2
Umleitungs-URIs konfigurieren
Nach der Registrierung gehen Sie zu Authentifizierung In der linken Leiste. Eine Plattform hinzufügen: Auswahl Web. Fügen Sie Ihre Ihren Redirect-URI(s) hinzu, die URL zurück, zu der Microsoft den Benutzer mit dem Autorisierungscode weiterleitet.
Plattformtyp
Web für serverseitige Apps. Verwenden Sie Single-Page Application (SPA) für clientseitige Flows (aktiviert automatisch PKCE).
Weiterleitungs-URI
In der Produktion muss HTTPS verwendet werden. Beispiel: https://app.yourproduct.com/auth/microsoft/callback. Es ist eine exakte Übereinstimmung erforderlich; jede Abweichung führt zum Fehler AADSTS50011.
Abmelde-URL (optional)
Microsoft wird diese URL aufrufen, wenn sich der Benutzer aus einer beliebigen App in seinem Mandanten abmeldet. Optional für reine E-Mail-Integrationen.
Häufiger Fehler: URIs mit „localhost“ sind während der Entwicklung zulässig (http://localhost:3000/callback), Produktions-URIs müssen jedoch HTTPS verwenden. Registrieren Sie beide separat.
3
Microsoft Graph-API-Berechtigungen hinzufügen
Geh API-Berechtigungen. Klicken + Berechtigung hinzufügen, wählen Sie Microsoft Graph, dann Delegierte Berechtigungen. Füge die Berechtigungen hinzu, die deine App benötigt.
Minimum zum Lesen
Mail.Lesen, Offline-Zugriff, openid, Profil
Zum Lesen + Senden
Mail.ReadWrite, Mail.Senden, Offline-Zugriff, openid, Profil
Offline-Zugriff
Kritisch. Ohne diesen Geltungsbereich stellt Microsoft keinen Aktualisierungstoken aus. Ihre Benutzer müssen sich alle 60-90 Minuten erneut authentifizieren.
Anmerkung: Das Hinzufügen von Berechtigungen an dieser Stelle bedeutet nicht, dass diese bereits erteilt werden, sondern dient lediglich als Absichtserklärung. Der Nutzer erteilt seine Zustimmung, wenn er den OAuth-Ablauf abschließt. Für einige Bereiche mit erweiterten Berechtigungen ist die Zustimmung eines Administrators erforderlich (siehe Abschnitt 7).
4
Generiere einen Client-Secret
Geh Zertifikate und Geheimnisse. Klicken + Neues Clients-Geheimnis. Legen Sie eine Beschreibung und ein Ablaufdatum fest.
Haltbarkeitsdatum / Empfehlung zum Verfallsdatum
730 Tage (24 Monate) ist das Maximum. Richten Sie eine Kalendererinnerung 60 Tage vor Ablauf ein, da die Rotation eines abgelaufenen Geheimnisses sofortige Authentifizierungsfehler bei allen Benutzern verursacht.
Den Wert sofort kopieren
Der geheime Wert wird nur einmal angezeigt. Speichern Sie ihn in Ihrem Geheimnismanager (z. B. AWS Secrets Manager, HashiCorp Vault, Azure Key Vault). Er wird nie wieder angezeigt, nachdem Sie diese Seite verlassen haben.
Empfohlene Alternative: Für die Produktion sollte anstelle eines Client-Secrets ein Zertifikat verwendet werden. Zertifikate sind sicherer (asymmetrischer Schlüssel), laufen niemals versehentlich ab und werden von Microsoft für unternehmenstaugliche Anwendungen bevorzugt.
5
Kopiere deine Client-ID und Tenant-ID
Vom Übersicht Seite Ihrer App-Registrierung, kopieren Sie zwei Werte, die Sie in jeder OAuth-Anfrage benötigen:
Anwendungs-(Client-)ID
Eine UUID, die Ihre App-Registrierung eindeutig identifiziert. Wird als client_id Parameter in allen Authentifizierungsanfragen.
Verzeichnis (Mandanten-) ID
Die Mandanten-ID Ihrer Organisation. Wird in Single-Tenant-Autorisierungs-URLs verwendet. Für mandantenfähige Apps verwenden Sie /gemeinsam stattdessen, behalten Sie diesen Wert für Admin-Zustimmungs-URLs bei.
6
ID-Token aktivieren (optional, aber empfohlen)
Zurück in Authentifizierung, unter Implizite Zustimmung und hybride Flows, Sie können aktivieren ID-Tokens. Damit können Sie neben dem Zugriffstoken eine JWT mit Benutzeridentitätsansprüchen (Name, E-Mail, Tenant-ID) empfangen, was für Onboarding-Workflows nützlich ist, bei denen Sie Benutzerprofildaten vorab ausfüllen möchten.
Leitlinien für 2026: Für reine Auth-Code-Flows + PKCE werden ID-Tokens über den Token-Endpunkt zurückgegeben, nicht über den impliziten Grant. Sie müssen den impliziten Grant nicht aktivieren. Aktivieren Sie ihn nur, wenn Sie eine ältere SPA haben, die PKCE nicht verwenden kann.
7
Optional: Bestätigen Sie Ihre Publisher-Domain
Unter Branding und Immobilien, setzen Sie Ihre Publisher-Domain auf die Domain Ihres Produkts. Dies ersetzt die Kennzeichnung "nicht verifiziert" auf dem Zustimmungsbildschirm durch Ihren Domainnamen. Für Mandantenanwendungen, die auf Unternehmenskunden abzielen, werden durch die Microsoft Partner Network-Verifizierung und den Status "verifizierter Publisher" die Warnung "Diese App wird nicht häufig verwendet" entfernt.
Verlag Domäne
Eine Domain, die Ihnen gehört und die Sie über einen TXT-Eintrag oder den Azure App Service-Domain-Validierungsablauf verifiziert haben.
Verifizierter Herausgeber
Erfordert eine Microsoft Partner Network (MPN) ID, die mit einer verifizierten Geschäftsidentität verknüpft ist. Dauert 1–5 Werktage. Verbessert die Konversionsrate von Unternehmenskunden auf Zustimmungsbildschirmen erheblich.
Überspringen Sie die Einrichtung: Bauen Sie stattdessen mit Unipile
Autorisierungs-Endpunkte

Die Wahl des richtigen Microsoft-Autorisierungs-Endpunkts

Die Autoritäts-URL, die Sie in Ihren OAuth-Anforderungen verwenden, bestimmt, welche Arten von Microsoft-Konten authentifiziert werden können und welche Token Sie erhalten. Wenn Sie diese falsch festlegen, kommt es zu stillen Fehlern, bei denen sich einige Benutzer überhaupt nicht authentifizieren können.

Autoritäts-URL Akzeptiert Anwendungsfall Vorbehalte
/gemeinsamMeiste SaaS Sowohl Microsoft Entra (Arbeit/Schule) als auch persönliche Microsoft-Konten (Outlook.com, Hotmail, Live) Multi-Tenant-SaaS für alle Microsoft-Benutzer. Endpunkt-Einheitlichkeit für Ihre gesamte Benutzerbasis. Token werden von jedem Benutzer-Heim-Mandanten ausgestellt, nicht von Ihrem. Die Token-Validierung muss den mandantenspezifischen Aussteller verwenden oder mehrere Aussteller akzeptieren. Richtlinien für bedingten Zugriff können nicht erzwungen werden.
/Organisationen Nur Microsoft Entra ID-Konten (beruflich/schulisch). Keine persönlichen Microsoft-Konten. B2B-SaaS, das sich ausschließlich an Unternehmenskunden richtet, niemals an private Outlook.com-Nutzer. Nutzer mit persönlichen Microsoft-Konten erhalten eine Fehlermeldung. Einfachere Token-Validierung (Muster mit einem Aussteller akzeptabel).
/Verbraucher Nur persönliche Microsoft-Konten (Outlook.com, Hotmail, Live). Verbraucher-Apps, die auf persönliche Posteingänge abzielen. Selten für B2B-SaaS. Enterprise-Microsoft-365-Konten werden abgelehnt. Nicht nützlich für SaaS, das Geschäftskunden bedient.
/{tenant-id} Konten in einem bestimmten Microsoft Entra-Mandanten. Single-Tenant-Intrumentierung (eigene Unternehmensanwendung). Admin-Zustimmungsflüsse, die auf einen bestimmten Mandanten abzielen. Wird auch im Admin-Zustimmungs-Weiterleitungs-URL-Muster verwendet. Jeder zweite Mandantenbenutzer wird abgewiesen. Nur geeignet für interne Apps oder wenn bewusst auf den Mandanten eines Kunden beschränkt wird.
/gemeinsam Meiste SaaS
Akzeptiert Sowohl Microsoft Entra (Arbeit/Schule) als auch persönliche Microsoft-Konten (Outlook.com, Hotmail, Live)
Anwendungsfall Multi-Tenant-SaaS für alle Microsoft-Benutzer. Endpunkt-Einheitlichkeit für Ihre gesamte Benutzerbasis.
Vorbehalte Token werden von jedem Benutzer-Heim-Mandanten ausgestellt, nicht von Ihrem. Die Token-Validierung muss den mandantenspezifischen Aussteller verwenden oder mehrere Aussteller akzeptieren. Richtlinien für bedingten Zugriff können nicht erzwungen werden.
/Organisationen
Akzeptiert Nur Microsoft Entra ID-Konten (beruflich/schulisch). Keine persönlichen Microsoft-Konten.
Anwendungsfall B2B-SaaS, das sich ausschließlich an Unternehmenskunden richtet, niemals an private Outlook.com-Nutzer.
Vorbehalte Nutzer mit persönlichen Microsoft-Konten erhalten eine Fehlermeldung. Einfachere Token-Validierung (Muster mit einem Aussteller akzeptabel).
/Verbraucher
Akzeptiert Nur persönliche Microsoft-Konten (Outlook.com, Hotmail, Live).
Anwendungsfall Verbraucher-Apps, die auf persönliche Posteingänge abzielen. Selten für B2B-SaaS.
Vorbehalte Enterprise-Microsoft-365-Konten werden abgelehnt. Nicht nützlich für SaaS, das Geschäftskunden bedient.
/{tenant-id}
Akzeptiert Konten in einem bestimmten Microsoft Entra-Mandanten.
Anwendungsfall Single-Tenant-Intrumentierung (eigene Unternehmensanwendung). Admin-Zustimmungsflüsse, die auf einen bestimmten Mandanten abzielen. Wird auch im Admin-Zustimmungs-Weiterleitungs-URL-Muster verwendet.
Vorbehalte Jeder zweite Mandantenbenutzer wird abgewiesen. Nur geeignet für interne Apps oder wenn bewusst auf den Mandanten eines Kunden beschränkt wird.
Token-Validierungs-Hinweis für /common: Wenn du das verwendest /gemeinsam Endpunkt, der isst Der Anspruch (issuer) im JWT wird https://login.microsoftonline.com/{tenantId}/v2.0 wo {mandantenId} variiert je nach Benutzer. Konfigurieren Sie Ihre JWT-Validierungsbibliothek so, dass jeder Aussteller akzeptiert wird, der mit https://login.microsoftonline.com/{tenantId}/v2.0 anstelle einer festen Ausstellerzeichenkette.
E-Mail-Bereiche

Microsoft Graph Mail-Bereiche: Granulare Aufschlüsselung

Microsoft Graph verwendet Berechtigungsumfänge, um zu steuern, was Ihre Anwendung tun kann. Das Anfordern zu vieler Umfänge erhöht die Hürden auf dem Zustimmungsbildschirm und verringert die Konversionsrate. Das Anfordern zu weniger Umfänge verursacht Laufzeitfehler. Hier sind alle E-Mail-Bereiche, die Sie kennen müssen.

Umfang Typ Was sie ermöglicht Admin-Zustimmung?
Mail.Lesen Delegiert Liest alle Nachrichten im Postfach des authentifizierten Benutzers. Beinhaltet Header, Körper, Anhänge. Nur Lesezugriff – kann nicht ändern oder senden. Benutzer
Mail.ReadBasic Delegiert Begrenzte Nachrichteneigenschaften lesen: Betreff, Absender, Empfänger, Datum. Nachrichtentext oder Anhänge können nicht gelesen werden. Nützlich für leichtgewichtige Posteingangslisten ohne vollständigen Zugriff auf den Inhalt. Benutzer
Mail.ReadWrite Delegiert Alle Nachrichten lesen und ändern. Beinhaltet das Erstellen, Aktualisieren und Löschen von Nachrichten und Ordnern. Obermenge von Mail.Read – fordern Sie nicht beides an. Benutzer
Mail.Senden Delegiert E-Mails als der authentifizierte Benutzer senden. Erforderlich, auch wenn Sie Mail.ReadWrite haben – das Senden ist eine separate Berechtigung in Microsoft Graph. Benutzer
Mail.Read.Shared Delegiert E-Mails in freigegebenen Postfächern oder Postfächern anderer Benutzer lesen, auf die der authentifizierte Benutzer Zugriff erhalten hat. Nicht zum Lesen des eigenen Postfachs des Benutzers. Benutzer
Mail.ReadWrite.Shared Delegiert E-Mails in gemeinsam genutzten Postfächern lesen und ändern, auf die der Benutzer Zugriff hat. Benutzer
Mail.Senden.Freigegeben Delegiert E-Mails von freigegebenen Postfächern oder "im Auftrag von" einem anderen Benutzer senden (wenn der Benutzer den Zugriff gewährt hat). Benutzer
Offline-Zugriff Delegiert Weist Microsoft an, einen Refresh-Token auszustellen. Ohne diesen erhalten Sie nur einen kurzlebigen Access-Token ohne Möglichkeit zur Erneuerung. Immer erforderlich für SaaS-Anwendungen. Benutzer
openid Delegiert Gibt ein ID-Token mit grundlegenden Benutzeridentitätsinformationen zurück. Erforderlich, wenn Sie wissen möchten, wer sich authentifiziert hat, ohne einen separaten /me API-Aufruf zu tätigen. Benutzer
Profil Delegiert Fügt die Claims "name" und "preferred_username" zum ID-Token hinzu. Wird normalerweise mit OpenID eingeschlossen. Benutzer
Mail.Read (App) Anmeldung Liest alle E-Mails in allen Postfächern im Mandanten ohne Benutzerinteraktion. Wird von Daemon-Diensten verwendet. Erfordert die Zustimmung des Mandantenadministrators. Administrator gesucht
Mail.ReadWrite (App) Anmeldung Alle E-Mails in allen Tenant-Postfächern lesen und schreiben. Sehr weitreichende Erlaubnis. Nur für vertrauenswürdige interne Tools mit ausdrücklicher Zustimmung des Tenant-Admins. Administrator gesucht
Mail.Lesen Delegiert
Liest alle Nachrichten im Postfach des authentifizierten Benutzers. Beinhaltet Header, Körper, Anhänge. Nur Lesezugriff – kann nicht ändern oder senden.
Einwilligung des Nutzers
Mail.ReadBasic Delegiert
Begrenzte Nachrichteneigenschaften lesen: Betreff, Absender, Empfänger, Datum. Nachrichtentext oder Anhänge können nicht gelesen werden. Nützlich für leichtgewichtige Posteingangslisten ohne vollständigen Zugriff auf den Inhalt.
Einwilligung des Nutzers
Mail.ReadWrite Delegiert
Alle Nachrichten lesen und ändern. Beinhaltet das Erstellen, Aktualisieren und Löschen von Nachrichten und Ordnern. Obermenge von Mail.Read – fordern Sie nicht beides an.
Einwilligung des Nutzers
Mail.Senden Delegiert
E-Mails als der authentifizierte Benutzer senden. Erforderlich, auch wenn Sie Mail.ReadWrite haben – das Senden ist eine separate Berechtigung in Microsoft Graph.
Einwilligung des Nutzers
Mail.Read.Shared Delegiert
E-Mails in freigegebenen Postfächern oder Postfächern anderer Benutzer lesen, auf die der authentifizierte Benutzer Zugriff erhalten hat. Nicht zum Lesen des eigenen Postfachs des Benutzers.
Einwilligung des Nutzers
Mail.ReadWrite.Shared Delegiert
E-Mails in gemeinsam genutzten Postfächern lesen und ändern, auf die der Benutzer Zugriff hat.
Einwilligung des Nutzers
Mail.Senden.Freigegeben Delegiert
E-Mails von freigegebenen Postfächern oder "im Auftrag von" einem anderen Benutzer senden (wenn der Benutzer den Zugriff gewährt hat).
Einwilligung des Nutzers
Offline-Zugriff Delegiert
Weist Microsoft an, einen Refresh-Token auszustellen. Ohne diesen erhalten Sie nur einen kurzlebigen Access-Token ohne Möglichkeit zur Erneuerung. Immer erforderlich für SaaS-Anwendungen.
Einwilligung des Nutzers
openid Delegiert
Gibt ein ID-Token mit grundlegenden Benutzeridentitätsinformationen zurück. Erforderlich, wenn Sie wissen möchten, wer sich authentifiziert hat, ohne einen separaten /me API-Aufruf zu tätigen.
Einwilligung des Nutzers
Profil Delegiert
Fügt die Claims "name" und "preferred_username" zum ID-Token hinzu. Wird normalerweise mit OpenID eingeschlossen.
Einwilligung des Nutzers
Mail.Read (App) Anmeldung
Liest alle E-Mails in allen Postfächern im Mandanten ohne Benutzerinteraktion. Wird von Daemon-Diensten verwendet. Erfordert die Zustimmung des Mandantenadministrators.
Administrator gesucht
Mail.ReadWrite (App) Anmeldung
Alle E-Mails in allen Tenant-Postfächern lesen und schreiben. Sehr weitreichende Erlaubnis. Nur für vertrauenswürdige interne Tools mit ausdrücklicher Zustimmung des Tenant-Admins.
Administrator gesucht
Minimaler Umfang-Set: Posteingangsleser
scope=Mail.Readoffline_accessopenidprofile
Nachrichten lesen, Tokens aktualisieren, Benutzeridentität. Keine Schreib- oder Sendeoptionen.
Standard-Umfang: volle E-Mail-Integration
scope=Mail.ReadWriteMail.Sendoffline_accessopenidprofile
Lesen, schreiben, senden. Das gängigste Set für CRM- und Vertriebstool-Integrationen.
Siehe die vollständige E-Mail-API-Anleitung
Berechtigungsmodell

Delegierte vs. Anwendungsberechtigungen: Wann welche gilt

Microsoft Graph verwendet zwei grundlegend unterschiedliche Berechtigungsmodelle. Die meisten SaaS-Entwickler greifen standardmäßig zum falschen Modell, was zu unnötigen Administratorzustimmungen und einer schlechten Benutzererfahrung führt. Hier wird genau erklärt, wann welches Modell zu verwenden ist.

Delegierte Berechtigungen
Im Namen des angemeldeten Benutzers handeln
Die App greift mithilfe der Identität des authentifizierten Benutzers auf Microsoft Graph zu. Die App kann nur das tun, was der Benutzer selbst tun könnte. Wenn der Benutzer einen Ordner nicht lesen kann, kann Ihre App dies ebenfalls nicht.
Nutzer stimmt während des OAuth-Flows zu – kein Administrator für Standardbereiche erforderlich
Der Zugriff ist auf das Postfach des jeweiligen Benutzers beschränkt
Benutzer können den Zugriff jederzeit über die Einstellungen ihres Microsoft-Kontos widerrufen
Berücksichtigt benutzerebene Berechtigungen, Rollenzuweisungen und Postfachzugriffsrichtlinien
Verwenden Sie dies für SaaS-Anwendungen, bei denen sich jeder Benutzer einzeln authentifiziert
Anwendungsberechtigungen
Agieren Sie als die Anwendung selbst
Die Anwendung greift ohne Anwesenheit eines Benutzers auf Microsoft Graph zu. Wird für Hintergrunddienste, Dämonen und automatisierte Workflows verwendet. Die Anwendung authentifiziert sich über ihre eigenen Anmeldeinformationen (Client-Credentials-Flow).
Erfordert die Zustimmung des Mandantenadministrators – ein erhebliches Hindernis für externe Benutzer
Der Zugriff gilt für alle Mandanten – nach Zustimmung des Administrators können ALLE Postfächer eingesehen werden
Keine interaktive Benutzeranmeldung erforderlich – funktioniert für Headless-Automatisierung
Geeignet für interne IT-Tools, bei denen der Administrator Ihrer Organisation die Bereitstellung steuert
Nur für interne Tools, bei denen der Administrator Ihres Unternehmens vollen Mandantenzugriff gewährt
Die SaaS-Entscheidungsregel
Wenn Sie bauen Produkt, das von externen Kunden verwendet wird wer sich einzeln anmeldet, benutzt Delegierte Berechtigungen. Jeder Kunde authentifiziert sich mit seinem eigenen Microsoft-Konto, stimmt den Geltungsbereichen Ihrer App zu, und Ihre App arbeitet im Namen von des authentifizierten Benutzers. Anwendungsberechtigungen erfordern, dass ein Mandantenadministrator Ihre App für seine gesamte Organisation vorab genehmigt – ein Schritt, der in einem Self-Service-SaaS-Funnel die Konversion stark beeinträchtigt. Die einzige Ausnahme besteht, wenn Sie ein internes Unternehmenswerkzeug erstellen, das von Ihrem eigenen IT-Team in Ihrem eigenen Mandanten bereitgestellt wird.
Vollständige Komplettlösung

Auth-Code + PKCE: Schritt-für-Schritt-Beispiele mit Curl

Hier ist der vollständige Microsoft Graph OAuth 2.0 Autorisierungscodefluss mit PKCE, von der Generierung des Code-Verifiers bis zum Token-Austausch. Dies sind produktionsreife Beispiele, die Sie direkt für Ihren Stack anpassen können.

Schritt 1 von 4 - PKCE-Parameter generieren
code_verifier und code_challenge generieren
PKCE funktioniert, indem ein zufälliges Geheimnis (code_verifier) generiert wird, dann ein SHA-256-Hash davon (code_challenge). Du sendest die Challenge in Schritt 2 und den Verifier in Schritt 4. Microsoft überprüft, ob sie übereinstimmen, und verhindert so Code-Abfangung.
pkce_erzeugen.py
import os, base64, hashlib # 1. code_verifier generieren (43–128 Zeichen, URL-kompatibles Base64) Code-Verifizierer = Base64.urlsafe_b64encode( os.urandom(32) ).dekodieren('utf-8').rstrip('=') # 2. code_challenge generieren = BASE64URL(SHA256(code_verifier)) code_challenge = Base64.urlsafe_b64encode( hashlib.sha256(code_verifier.kodieren('utf-8')).Verdauung() ).dekodieren('utf-8').rstrip('=') # Speichere „code_verifier“ in der Sitzung – du benötigst ihn in Schritt 4 # Code_challenge in der Autorisierungs-URL senden
Schritt 2 von 4 - Autorisierungsanfrage
Bauen Sie die /authorize-URL und leiten Sie den Benutzer weiter
Leiten Sie den Browser des Benutzers zum Autorisierungsendpunkt von Microsoft weiter. Der Benutzer sieht die Anmeldeseite von Microsoft, authentifiziert sich und stimmt den Gültigkeitsbereichen Ihrer Anwendung zu. Microsoft leitet dann mit einem Autorisierungscode zurück zu Ihrer redirect_uri weiter.
client_id
Ihre Anwendungs- (Client-) ID aus der Entra-App-Registrierung
Antworttyp
Code - fordert einen Autorisierungscode an
redirect_uri
Muss exakt mit einer in Ihrer Entra-App registrierten URI übereinstimmen. URL-kodiert.
Umfang
Leerzeichengetrennte Liste. Immer enthalten Offline-Zugriff für Token zur Verlängerung.
Zustand
Undurchsichtiger Wert, den Sie generieren. Unverändert im Rückruf zurückgegeben. Verwenden Sie ihn, um CSRF zu verhindern und den UI-Zustand wiederherzustellen.
code_challenge
Der BASE64URL(SHA256(code_verifier))-Wert aus Schritt 1.
code_challenge_methode
S256 - immer SHA-256 verwenden, niemals unverschlüsselt
authorize_url.sh
# Erstellen der Autorisierungs-URL (Format zur besseren Lesbarkeit) AUTH_URL="https://login.microsoftonline.com/common/oauth2/v2.0/authorize ?client_id=IHR_CLIENT_ID &response_type=code &redirect;_uri=https://app.comauthmscb &scope;=Mail.ReadWriteMail.Sendoffline_access &zustand=ZUFALLSWERT_DES_ZUSTANDS &code_challenge=DEIN_CODE_CHALLENGE &code_challenge_method=S256" # Den Benutzer an $AUTH_URL weiterleiten # Microsoft übernimmt die Anmeldung, die Multi-Faktor-Authentifizierung und den Einwilligungsbildschirm # Bei Erfolg: redirect_uri?code=AUTH_CODE&state;=...
Schritt 3 von 4 - Callback verarbeiten
Den Autorisierungscode an Ihre redirect_uri senden
Microsoft leitet Sie zu Ihrer redirect_uri weiter mit einem Code Abfrageparameter. Validieren Sie die Zustand Der Parameter stimmt mit dem überein, was Sie gesendet haben. Der Code ist 10 Minuten gültig – tauschen Sie ihn sofort in Schritt 4 um.
Schritt 4 von 4 – Token-Austausch
Tauschen Sie den Autorisierungscode gegen Zugangs- und Aktualisierungstokens ein
POSTe den Code und deinen `code_verifier` an den Token-Endpunkt. Microsoft gibt ein Zugriffstoken (ca. 60-90 Minuten gültig) und ein Aktualisierungstoken (langfristig gültig) zurück. Speichere beide sicher.
token_exchange.sh
#-Autorisierungscode für Token curl -X POST "https://login.microsoftonline.com/common/oauth2/v2.0/token" \ -H "Inhaltstyp: Anwendung/x-www-form-urlencoded" \ -d "client_id=DEINE_CLIENT_ID" \ -d "client_secret=DEIN_CLIENT_SECRET" \ -d "grant_type=authorization_code" \ -d "code=AUTH_CODE_FROM_CALLBACK" \ -d "redirect_uri=https://app.com/auth/ms/cb" \ -d "code_verifier=DEIN_CODE_VERIFIER" \ -d "Mail.ReadWrite Mail.Send offline_access"
Rückgaben: access_token, refresh_token, expires_in, scope
Schlüssel_Antwort.json
{ "token_typ": "Inhaber", "Umfang": "Mail.ReadWrite Mail.Send offline_access", "gültig_bis": 3600, "Zugriffstoken": "eyJ0eXAiOiJKV1Qi...", "Aktualisierungstoken": "0.ARoAi7W...", "id_token": "eyJ0eXAi..." }
Token-Lebenszyklus

Refresh-Token-Handhabung: Rotation, Ablauf und bedingter Zugriff

Microsoft Graph-Aktualisierungstoken haben eine lange Lebensdauer, sind aber nicht permanent. Mehrere Bedingungen können sie stillschweigend ungültig machen. Das Verständnis dieser Randfälle unterscheidet eine produktionsreife Microsoft OAuth-Integration von einer, die bei Unternehmensbenutzern zufällig ausfällt.

Ablauf der Inaktivität nach 90 Tagen
Microsoft-Aktualisierungstoken laufen nach 90 Tagen Inaktivität ab. Wenn ein Benutzer Ihre App 90 Tage lang nicht verwendet, wird sein Aktualisierungstoken ungültig und er muss sich erneut authentifizieren. Es gibt keine Möglichkeit, dies ohne Benutzerinteraktion zu verlängern. Behandeln Sie immer ungültiger_grant Fehler elegant behandeln und zur erneuten Authentifizierung auffordern.
Richtlinien für bedingten Zugriff – Änderungen
Unternehmensmandanten verwenden Richtlinien für bedingten Zugriff (MFA-Anforderungen, Gerätekonformität, Standortbeschränkungen). Wenn sich eine Richtlinie nach der Authentifizierung eines Benutzers ändert, kann dessen Token-Aktualisierung bei der nächsten Verwendung ungültig werden. Dies ist eine Entscheidung auf Kundenseite – Sie können sie nicht steuern oder vorhersagen. Leiten Sie Authentifizierungsfehler immer mit einer klaren Aufforderung zur erneuten Authentifizierung an die Benutzer weiter.
Tokenrotation für Aktualisierungs-Tokens
Wenn Sie einen Aktualisierungstoken verwenden, um einen neuen Zugriffstoken zu erhalten, kann Microsoft einen neuen Aktualisierungstoken ausstellen. Speichern Sie immer den neuen Aktualisierungstoken aus der Antwort und ersetzen Sie den alten. Wenn Sie weiterhin den alten Aktualisierungstoken verwenden, nachdem er rotiert wurde, werden Sie schließlich auf eine ungültiger_grant Fehler.
Admin-Widerruf
Ein Mandantenadministrator kann jederzeit alle Aktualisierungstoken für einen Benutzer oder die gesamte Organisation widerrufen (z. B. wenn ein Mitarbeiter das Unternehmen verlässt oder bei einem Sicherheitsvorfall). Ihre App empfängt ungültiger_grant. Dies ist das erwartete Verhalten – gehen Sie damit um, indem Sie das verknüpfte Konto als zur erneuten Autorisierung markieren.
refresh_token.sh
# Aktualisiere das Zugriffstoken mithilfe des gespeicherten Aktualisierungstokens curl -X POST "https://login.microsoftonline.com/common/oauth2/v2.0/token" \ -H "Inhaltstyp: Anwendung/x-www-form-urlencoded" \ -d "client_id=DEINE_CLIENT_ID" \ -d "client_secret=DEIN_CLIENT_SECRET" \ -d "grant_type=refresh_token" \ -d "refresh_token=GESPEICHERTER_REFRESH_TOKEN" \ -d "Mail.ReadWrite Mail.Send offline_access" # Überprüfen Sie in der Antwort IMMER, ob ein neues refresh_token vorhanden ist. # Falls vorhanden, das gelagerte Teil sofort austauschen. # Wenn die Fehlermeldung „invalid_grant“ angezeigt wird, fordern Sie den Benutzer auf, sich erneut zu authentifizieren.
Fehlerbehebung

Häufige AADSTS-Fehler entschlüsselt

Microsoft Graph OAuth-Fehler folgen einem konsistenten AADSTS-Fehlercodemuster. Dies sind die häufigsten, denen Sie bei der Entwicklung und Produktion begegnen werden, mit genauen Ursachen und Behebungen.

Fehlercode Was es bedeutet Grundursache und Behebung
AADSTS65001 Die Zustimmung für einen oder mehrere der angeforderten Bereiche wurde nicht erteilt Der Nutzer hat den Geltungsbereichen Ihrer App nicht zugestimmt, oder ein Mandantenadministrator hat die Zustimmung des Nutzers für Ihre App blockiert. Behebung: Fügen Sie Zustimmung in Ihrer Autorisierungs-URL, um die erneute Anzeige des Zustimmungsbildschirms zu erzwingen, oder senden Sie die Admin-Zustimmungs-URL an den Mandantenadministrator.
Füge Aufforderung=Zustimmung oder Administratorzustimmung anfordern hinzu
AADSTS50011 Fehler bei der Weiterleitungs-URI Die redirect_uri in Ihrer Anfrage nicht exakt mit einer registrierten Weiterleitungs-URI in Ihrer Entra-App-Registrierung übereinstimmt. Schon ein Unterschied bei einem nachgestellten Schrägstrich führt dazu. Lösung: Kopieren Sie die exakte URI aus Ihrer Entra-App-Registrierung und verwenden Sie sie wörtlich.
Behebung: Exakte URI-Übereinstimmung in der Entra-App-Registrierung
AADSTS700016 Anwendung im Mandanten nicht gefunden Die client_id existiert nicht im Mandanten, gegen den die Authentifizierung durchgeführt wird. Tritt häufig bei der Verwendung einer mandantenspezifischen Autorität auf (/{tenant-id}) für eine Mandantenanwendung. Behebung: Verwenden /gemeinsam oder /Organisationen Autorität für Mandantenanwendungen.
Korrektur: Wechseln Sie zur Berechtigung /common oder /organizations
AADSTS90099 Die Anwendung wurde in diesem Mandanten nicht autorisiert (consent_required) Die App existiert, wurde aber im Mandanten des Benutzers nicht genehmigt. Unterscheidet sich von AADSTS65001 dadurch, dass die gesamte App blockiert ist, nicht nur bestimmte Bereiche. Lösung: Senden Sie die Administrator-Zustimmungs-URL an den IT-Administrator des Kunden.
Beheben: Admin-Zustimmungs-URL zum Kunden-Mandanten-Administrator
AADSTS70011 Der bereitgestellte Zuschuss ist ungültig oder abgelaufen Der Refresh-Token oder der Autorisierungscode ist abgelaufen oder wurde widerrufen. Autorisierungscodes laufen nach 10 Minuten ab. Refresh-Tokens laufen nach 90 Tagen Inaktivität oder Widerruf durch den Administrator ab. Behebung: Fordern Sie den Benutzer auf, die Authentifizierung vom Anfang des OAuth-Flows aus neu durchzuführen.
Behebung: Vollständige Re-Authentifizierung auffordern
AADSTS50076 Eine MFA ist für diese Richtlinie für bedingten Zugriff erforderlich Der Mandant des Benutzers erfordert die multifaktorielle Authentifizierung für deine App. Dies ist eine kundenabhängige Entscheidung, die vom Mandantenadministrator erzwungen wird. Deine App kann dies nicht umgehen. Der Benutzer muss die MFA abschließen. Bei Verwendung des Autorisierungscode-Ablaufs wird Microsoft die MFA-Aufforderung automatisch im Browser anzeigen. Probleme treten bei automatisierten Abläufen (Client-Anmeldeinformationen) auf, die die MFA nicht abschließen können.
Erwartet: Benutzer muss MFA abschließen
Es gibt ein Problem mit der Anmeldung Ihres Kontos vom Typ "Identitätsanbieter" aus. Benutzerkonto vom externen Identitätsanbieter existiert nicht im Mandanten Der Benutzer versucht, sich mit einem persönlichen Microsoft-Konto in einem Mandanten zu authentifizieren, der nur organisatorische Konten zulässt, oder umgekehrt. Korrektur: Überprüfen Sie Ihren Autorisierungsendpunkt – wenn Sie ihn verwenden /Organisationen, persönliche Konten können sich nicht authentifizieren. Wechseln Sie zu /gemeinsam wenn Sie beides brauchen.
Beheben: Autorität auf /common umschalten
Fehler Zugriff durch bedingte Zugriffrichtlinie blockiert Die bedingte Zugriffrichtlinie des Mieters hat diesen Authentifizierungsversuch vollständig blockiert (z. B. blockiertes Land, nicht verwaltetes Gerät, blockierte App). Dies ist eine Entscheidung auf Kundenseite. Sie können diese nicht überschreiben. Zeigen Sie dem Benutzer den Fehler an und weisen Sie ihn an, sich an seinen IT-Administrator zu wenden.
Kunden-Seite: Nutzer raten, sich an den IT-Administrator zu wenden
Lassen Sie Unipile das alles für Sie erledigen
Die Unipile Alternative

Überspringen Sie 5 Wochen OAuth-Plumbing mit Unipile

Alles in diesem Leitfaden – Entra-App-Registrierung, Authority-Endpunkte, Auswahl des Gültigkeitsbereichs, PKCE, Tokenrotation, Behandlung von AADSTS-Fehlern – ist Entwicklungszeit, die Ihr Produkt nicht voranbringt. Unipile verwaltet den gesamten Microsoft Graph OAuth-Stack als verwalteten Dienst, sodass Ihr Team anstelle von 500 Zeilen OAuth-Infrastrukturcode nur einen API-Aufruf schreibt.

Selbst bauen
Entra App-Registrierung und -Konfiguration
PKCE-Implementierung und Code-Challenge-Generierung
Speicherung, Rotation und Behandlung von Ablaufdaten für Refresh-Token
Admin-Einwilligungsflow für Unternehmenskunden
AADSTS-Fehlerbehandlung und erneute Authentifizierungsaufforderungen
Rotation des Clientgeheimnisses vor dem Ablaufdatum
Handling von Ausnahmen für bedingten Zugriff pro Mandant
Getrennte OAuth-Stacks für Gmail und IMAP-Anbieter
Mit Unipile
Ein POST, um einen gehosteten Auth-Link zu generieren
Unipile verwaltet PKCE, Token und die Aktualisierung automatisch
Tokens werden nie in Ihrer Datenbank gespeichert – Unipile kümmert sich darum
Gleiche API für Microsoft-, Gmail- und IMAP-Konten
Webhook-Benachrichtigungen, wenn Konten eine erneute Authentifizierung benötigen
Branded Consent Screen mit Ihren eigenen Entra App-Anmeldeinformationen
Integrieren Sie Ihre E-Mail-Integration in Stunden statt in Wochen.
Wie Unipile Microsoft OAuth funktioniert
Ihr Backend ruft einen Endpunkt auf, um einen gehosteten Authentifizierungslink zu generieren. Ihr Benutzer klickt darauf, authentifiziert sich bei Microsoft und Unipile verwaltet den gesamten OAuth-Flow – Entra-Redirect, Scope-Handling, Token-Austausch und Aktualisierung. Das verknüpfte Konto ist dann über die einheitliche E-Mail-API von Unipile verfügbar.
unipile_microsoft_oauth.py
import Anfragen UNIPILE_API_URL = "https://apiXXX.unipile.com:XXX" UNIPILE_API_KEY = "dein-api-schlüssel" # Schritt 1: Erstellen Sie einen gehosteten Authentifizierungslink für Microsoft response = requests.Beitrag( f"{UNIPILE_API_URL}/api/v1/hosted/accounts/link", Kopfzeilen={ "X-API-KEY": UNIPILE_API_SCHLÜSSEL, "Content-Type": "application/json" }, json={ "Typ": "erstellen", "Anbieter": ["MICROSOFT"], "api_url": UNIPILE_API_URL, "giltBis": "2026-12-31T23:59:59Z", # Optional: Verknüpfen Sie diesen Link mit einem bestimmten Benutzer "Name": "user_id_123", # Optional: Benachrichtigung erhalten, wenn das Konto verknüpft ist "Benachrichtigungs-URL": "https://app.yourproduct.com/webhooks/account-linked" } ) # Schritt 2: Leiten Sie Ihren Benutzer auf diese URL weiter gehostete_auth_url = Antwort.json()["url"] Beispiel für #: https://account.unipile.com/[encoded-token] # Unipile-Funktionen: Entra-Weiterleitung, Einwilligungsbildschirm, PKCE, #-Token-Austausch, Aktualisierung des Token-Speichers, Bereichsverwaltung # Schritt 3: Nach der Authentifizierung die E-Mail-API von Unipile zum Lesen und Senden von E-Mails verwenden emails = Anfragen.bekommen.( f"{UNIPILE_API_URL}/api/v1/emails", Kopfzeilen={"X-API-KEY": UNIPILE_API_SCHLÜSSEL}, params={"Konto_ID": "verknüpftes-Konto-ID"} )
Microsoft OAuth abgeschlossen. Postfach über einheitliche API verfügbar.
Gehosteter Authentifizierungsablauf
Unipile hostet den OAuth-Einwilligungsbildschirm. Ihre Benutzer sehen einen sauberen, gebrandeten Ablauf. Keine Wartung der Weiterleitungs-URI, keine CORS-Probleme, kein Hin- und Herschalten zwischen lokalen und Produktions-URLs.
Token-Verwaltung
Unipile speichert und rotiert Microsoft OAuth-Token in Ihrem Namen. Token-Rotation für Aktualisierungstoken, Überwachung der Inaktivität über 90 Tage und Benachrichtigungen zur Reauthentifizierung werden automatisch verwaltet.
Vereinheitlichte E-Mail-API
Nach der Verknüpfung reagieren Microsoft-, Gmail- und IMAP-Mailboxen auf dieselben Unipile-E-Mail-Endpunkte. Eine Integration dient allen drei Anbietern.
Ihre eigenen Entra-Anmeldeinformationen
Konfigurieren Sie Ihre eigenen Microsoft Entra-App-Anmeldedaten im Unipile-Dashboard. Ihre Benutzer sehen Ihren App-Namen auf dem Zustimmungsbildschirm von Microsoft, nicht den von Unipile.
Webhook-Benachrichtigungen
Empfange einen Webhook, wenn ein verknüpftes Konto eine erneute Authentifizierung benötigt (abgelaufener Aktualisierungstoken, Administratorwiderruf, Änderung der bedingten Zugriffsrichtlinie). Zeige die Eingabeaufforderung zur erneuten Authentifizierung sofort in deinem Produkt an.
Lesen, senden und synchronisieren
Nach Microsoft OAuth über Unipile können Sie E-Mails lesen, E-Mails senden, Threads synchronisieren, Ordner verwalten und Anhänge verarbeiten - alles über die einheitliche E-Mail-API von Unipile. Kein separater Microsoft Graph-Client erforderlich.
Wie Unipile funktioniert
Unipile ist ein unabhängiger technischer Vermittler, der im Auftrag jedes authentifizierten Benutzers über von Microsoft ausgestellte OAuth-Token agiert. Wenn ein Benutzer seine Outlook- oder Microsoft 365-Mailbox verknüpft, arbeitet Unipile ausschließlich mit den delegierten Berechtigungen dieses Benutzers. Unipile ist nicht mit Microsoft verbunden, wird von Microsoft nicht unterstützt und nicht von Microsoft gesponsert. Wir nutzen die öffentliche Microsoft Graph API im Namen authentifizierter Endbenutzer. Jedes Konto agiert innerhalb der eigenen Microsoft Entra-Identität des Benutzers und der Richtlinien für bedingten Zugriff seiner Organisation.
Beginnen Sie mit dem Aufbau Ihres Microsoft OAuth-Flows MS Graph E-Mail-Leitfaden
FAQ

Häufig gestellte Fragen

Die häufigsten Fragen zu Microsoft Graph OAuth für die E-Mail-Integration, von der Auswahl des Gültigkeitsbereichs über den Tokenlebenszyklus bis hin zu Enterprise Consent Flows.

01
Funktioniert Microsoft Graph OAuth sowohl für Outlook.com- als auch für Microsoft 365-Konten?
Ja. Unter Verwendung des /gemeinsam Der Authentifizierungsendpunkt, eine einzelne Microsoft Entra-App-Registrierung, kümmert sich um die Authentifizierung sowohl für persönliche Outlook.com-Konten als auch für Microsoft 365-Arbeits-/Schulkonten. Der Schlüssel liegt in der Auswahl von "Konten in beliebigen Verzeichnissen und persönlichen Microsoft-Konten" bei der Registrierung Ihrer App im Azure-Portal.
02
Wenn ein Microsoft 365-Benutzer sein Unternehmen verlässt, werden die OAuth-Token, die er zur Authentifizierung bei Anwendungen und Diensten verwendet hat, im Allgemeinen ungültig. Dies geschieht aus mehreren Gründen: 1. **Automatische Widerrufung bei Deaktivierung des Kontos:** Wenn das Benutzerkonto in Microsoft 365 deaktiviert oder gelöscht wird, widerruft Microsoft die damit verbundenen Authentifizierungstoken automatisch. Dies ist ein wichtiger Sicherheitsschritt, um unbefugten Zugriff auf Unternehmensressourcen zu verhindern. 2. **Ende der Sitzungsgültigkeit:** OAuth-Token haben eine begrenzte Lebensdauer (Sitzungsgültigkeit). Selbst wenn das Konto nicht sofort deaktiviert wird, laufen die Token irgendwann ab. Bei einem ausscheidenden Mitarbeiter ist dies ein zusätzlicher Sicherheitsmechanismus. 3. **Überprüfung durch Anwendungen:** Anwendungen, die OAuth verwenden, um auf Microsoft 365 zuzugreifen, überprüfen die Gültigkeit des Tokens bei jeder Anfrage. Wenn das Token ungültig ist (weil das Konto deaktiviert wurde oder das Token abgelaufen ist), wird die Anfrage abgelehnt. 4. **Manuelle Widerrufung (optional):** Administratoren können in der Microsoft 365-Verwaltungskonsole oder über PowerShell auch manuell Widerrufe für bestimmte Token oder Sitzungen für einen ausscheidenden Benutzer durchführen, um sicherzustellen, dass kein Zugriff mehr möglich ist. Zusammenfassend lässt sich sagen, dass die OAuth-Tokens eines ausscheidenden Benutzers ihre Gültigkeit verlieren, wodurch der Zugriff auf die mit diesen Tokens geschützten Dienste und Daten effektiv blockiert wird. Dies ist ein integraler Bestandteil des Prozesses zur sicheren Abwicklung von Mitarbeiterabgängen in einer Microsoft 365-Umgebung.
Wenn ein IT-Administrator ein Benutzerkonto in Microsoft Entra ID deaktiviert oder löscht, werden alle Aktualisierungstoken dieses Benutzers sofort widerrufen. Ihr nächster Versuch, ein Token zu aktualisieren, gibt ein ungültiger_grant Fehler. Behandeln Sie dies anmutig: Markieren Sie das verknüpfte Konto als re-authentifizierungspflichtig und zeigen Sie eine klare Re-Authentifizierungsaufforderung in Ihrem Produkt an. Dies ist das erwartete Verhalten – eine Entscheidung auf Kundenseite, die außerhalb Ihrer Kontrolle liegt.
03
Benötigt die Administratoreinwilligung, um Outlook-E-Mails über Microsoft Graph OAuth zu lesen?
Nein, für Standardberechtigungen für delegierte Benutzerkonten. Mail.Lesen, Mail.ReadWriteund Mail.Senden sind benutzerfreundliche Gültigkeitsbereiche – einzelne Benutzer können diese während des OAuth-Flows genehmigen. Eine Administratoreinwilligung ist nur für Anwendungsberechtigungen oder hochprivilegierte Gültigkeitsbereiche wie erforderlich Benutzer.AlleLesen. Einige Enterprise-Tenants konfigurieren Richtlinien, die die Zustimmung zu Apps von Drittanbietern blockieren – dies ist eine Entscheidung des Kunden.
04
Wie lange sind Microsoft Graph-Aktualisierungstoken gültig?
Refresh-Tokens verfallen nach 90 Tagen Inaktivität. Solange Ihre App den Refresh-Token regelmäßig verwendet (was automatisch geschieht, wenn Access-Tokens vor ihrem Ablauf alle 60–90 Minuten aktualisiert werden), bleibt der Refresh-Token gültig. Änderungen an der Richtlinie für bedingten Zugriff, zurückgesetzte Passwörter oder eine Admin-Widerrufung können sie vorzeitig ungültig machen. Handhaben Sie immer ungültiger_grant Fehler und ersetze alte Aktualisierungstoken durch das neue, das in jeder Token-Antwort zurückgegeben wird.
05
Was ist der Unterschied zwischen AADSTS65001 und AADSTS90099?
AADSTS65001Der Nutzer hat noch keiner Zustimmung zu einem oder mehreren spezifischen Bereichen zugestimmt. Korrektur: hinzufügen Zustimmung zu Ihrer Autorisierungs-URL, um einen neuen Zustimmungsbildschirm zu erzwingen. AADSTS90099Die gesamte Anwendung wurde in diesem Mandanten nicht autorisiert – der Mandantenadministrator muss Ihre Anwendung vorab genehmigen. Senden Sie die URL für die Administratoreinwilligung an den IT-Administrator des Kunden. Beide Fehler treten häufig in Unternehmensszenarien auf, in denen Mandanten die Benutzereinwilligung einschränken.
06
Kann ich dieselbe Entra-Anwendungsregistrierung sowohl zum Lesen als auch zum Senden von E-Mails verwenden?
Ja. Beide anfordern Mail.ReadWrite und Mail.Senden im selben Geltungsbereich (scope) des Strings. Beachten Sie, dass Mail.ReadWrite und Mail.Senden sind separate Gültigkeitsbereiche – Lese-/Schreibzugriff gewährt nicht automatisch die Sendeberechtigung. Immer einschließen Offline-Zugriff um sicherzustellen, dass Sie einen Aktualisierungstoken erhalten. Siehe die E-Mail-API-Seite für Implementierungsdetails.
07
Speichert Unipile Microsoft OAuth-Token in meiner Datenbank?
Nein. Wenn Sie den gehosteten Microsoft-Authentifizierungsablauf von Unipile verwenden, verwaltet Unipile alle OAuth-Token in Ihrem Namen. Ihre Anwendung verarbeitet Microsoft-Zugriffstoken oder Aktualisierungstoken niemals direkt. Sie interagieren ausschließlich über die einheitliche E-Mail-API von Unipile mit verknüpften Konten, indem Sie Ihren Unipile-API-Schlüssel verwenden. Dadurch entfallen Anforderungen an die Token-Speicherung, -Rotation und -Sicherheit Ihrer eigenen Infrastruktur.
08
Ist Unipile mit Microsoft verbunden?
Nein. Unipile ist nicht mit Microsoft verbunden, wird von Microsoft nicht unterstützt und nicht von Microsoft gesponsert. Unipile ist ein unabhängiger technischer Vermittler, der die öffentliche Microsoft Graph API im Auftrag authentifizierter Endbenutzer nutzt. Jede Integration operiert über von Microsoft ausgestellte OAuth-Token unter der Identität des jeweiligen Benutzers und den Conditional Access-Richtlinien ihrer Organisation. Microsoft Graph und Microsoft Entra sind Marken der Microsoft Corporation.
Haben Sie noch Fragen? Unser Team kann Sie durch Microsoft Graph OAuth für Ihren spezifischen Anwendungsfall führen.
de_DEDE
en_USEN fr_FRFR es_ESES it_ITIT pt_BRBR nl_NLNL pl_PLPL tr_TRTR de_DEDE