Connected Apps mit .NET

Moderne Business-Anwendungen sind nur noch selten isolierte Systeme. Eine Anwendung, die Kundentermine verwaltet, arbeitet nicht mehr alleine mit einer eigenen Datenbank. Sie muss wissen, wann ein Mitarbeiter verfügbar ist, ob zu einem Termin bereits ein Teams-Meeting existiert, welche E-Mails zu einem Vorgang gehören, wo die zugehörigen Dokumente liegen und welche Personen im Unternehmen beteiligt sind. Für Entwickler bedeutet das: Die eigentliche Fachlogik einer Anwendung entsteht zunehmend im Zusammenspiel mit bestehenden Plattformdiensten.

Genau hier setzt der Gedanke der „Connected Apps“ an. Eine Connected App ist nicht nur eine Anwendung mit Internetverbindung, sondern eine Anwendung, die sich sinnvoll in den digitalen Arbeitskontext eines Unternehmens einfügt. Sie nutzt Identitäten, Kalender, Nachrichten, Dokumente, Teams, Gruppen und Berechtigungen nicht als getrennte Daten­inseln, sondern als zusammenhängenden Arbeitsraum. Ein Beispiel aus der Praxis ist eine interne Projektmanagement-Anwendung: Wird ein neuer Kundenworkshop angelegt, kann die Anwendung automatisch die Verfügbarkeit der Projektbeteiligten prüfen, einen Kalendereintrag erzeugen, ein Teams-Meeting hinzufügen, einen SharePoint-Ordner für die Unterlagen anlegen und später relevante E-Mails oder Dokumente dem Vorgang zuordnen. Ohne eine zentrale Integra­tionsschicht müsste jedes dieser Szenarien über eigene APIs, eigene Authentifizierungslogik und eigene Datenmodelle umgesetzt werden.

Microsoft 365 hat sich in vielen Unternehmen zur zentralen Arbeitsplattform entwickelt. Outlook, Teams, OneDrive, Share­Point und Entra ID bilden zusammen die technische Grundlage für Kommunikation, Zusammenarbeit, Identität und Dokumentenmanagement. Für .NET-Entwickler ist das besonders interessant, weil viele Unternehmensanwendungen ohnehin im Microsoft-Umfeld entstehen: als ASP.NET-Core-Webanwendung, Blazor-App, Desktop-Client, Web-API, Worker Service oder Azure Function. 

Das Microsoft Graph API übernimmt dabei die Rolle einer zentralen Integrationsschicht (Bild 1). Microsoft beschreibt Graph als Gateway zu Daten und Intelligenz in Microsoft-Clouddiensten wie Microsoft 365 und Microsoft Entra. Über eine einheitliche REST-Schnittstelle erhalten Anwendungen Zugriff auf Ressourcen wie Benutzer, Gruppen, Nachrichten, Kalender, Dateien, Sites, Teams und weitere Dienste. Für Entwickler reduziert sich dadurch die Komplexität: Statt für Outlook, SharePoint, Teams und Identitätsinformationen jeweils eigene Schnittstellen zu kombinieren, kann eine Anwendung über Microsoft Graph mit einem gemeinsamen Programmiermodell arbeiten.

Wichtig ist: Microsoft Graph ist nicht nur eine Sammlung technischer Endpunkte (Bild 2). Das API bildet Beziehungen zwischen Ressourcen ab und macht diese programmatisch nutzbar. Ein Benutzer hat Nachrichten, Termine, Dateien, Gruppenmitgliedschaften und Teams-Kontexte. Eine Datei liegt in OneDrive oder SharePoint, kann geteilt werden, besitzt Versionen und Berechtigungen. Ein Termin hat Teilnehmer, Räume, Online-Meeting-Informationen und Verfügbarkeitsbezüge. Diese Beziehungen machen Graph für kontextbezogene Anwendungen besonders wertvoll. Anwendungen können nicht nur Daten abrufen, sondern Zusammenhänge nutzen: Wer arbeitet woran? Welche Informationen gehören zu einem Vorgang? Welche Kommunikation ist für eine Entscheidung relevant?

Microsoft Graph im Microsoft-365-Ökosystem

Der Name „Graph“ ist dabei nicht zufällig gewählt. Es geht nicht nur um den Zugriff auf ­einzelne Datensätze, sondern um Beziehungen zwischen Ressourcen. Eine zentrale Rolle spielt Micro­soft Entra ID. Es bildet die Identitätsgrundlage für Microsoft-365-Umgebungen und damit auch für Graph-basierte Anwendungen. Jede Anwendung, die Microsoft Graph verwendet, muss registriert werden, benötigt Berechtigungen und erhält Zugriffstokens für konkrete Szenarien. Der Zugriff auf Microsoft-365-Daten beginnt nicht beim HTTP-Request, sondern bei Identität, Anmeldung, Berechtigungen und Zustimmung.

Outlook gehört zu den naheliegenden Einstiegsbereichen für Microsoft Graph. Viele Geschäftsanwendungen benötigen Zugriff auf Nachrichten, Kalender, Kontakte oder Verfügbarkeiten. Microsoft Teams erweitert diese Perspektive um Kommunikation und Zusammenarbeit in Gruppen. Teams ist für viele Unternehmen der zentrale Ort für Chats, Meetings, Kanäle und projektbezogene Abstimmung. Über Microsoft Graph lassen sich Teams, Kanäle, Chats, Nachrichten und Meeting-Kontexte in Anwendungen einbinden. OneDrive und SharePoint bilden den dokumentenorientierten Teil des Ökosystems. Anwendungen können über Microsoft Graph Dateien hochladen, herunterladen, Metadaten lesen, Freigaben verwalten oder Versionen berücksichtigen.

Das API verfolgt den Anspruch eines gemeinsamen Zugriffsmodells. Ressourcen werden über REST-Endpunkte adressiert, Antworten werden typischerweise als JSON geliefert, und viele Abfragen unterstützen Optionen wie Filterung, Projektion oder Sortierung.

Architektur, Zugriff und Entwicklung mit .NET

Eine typische Architektur beginnt mit der Frage, in welchem Kontext die Anwendung arbeitet. Eine Blazor-Webanwendung, die ein angemeldeter Benutzer im Browser verwendet, greift meist im Namen dieses Benutzers auf Microsoft Graph zu. Ein Worker Service, der nachts Dokumente synchronisiert oder Postfächer verarbeitet, arbeitet dagegen häufig ohne interaktive Anmeldung im Anwendungskontext. Eine mobile App, eine Desktop-Anwendung, ein ASP.NET-Core-Web-API und eine Azure Function haben jeweils andere Anforderungen an Anmeldung, Token-Verwaltung, Berechtigungen und Betrieb. Der erste Architekturentscheid lautet daher nicht, welcher Graph-Endpunkt verwendet wird, sondern welcher Anwendungstyp vorliegt und ob der Zugriff delegiert oder als Anwendung erfolgen soll. Ressourcen werden über URLs adressiert, Operationen über HTTP-Methoden wie GET, POST, PATCH oder DELETE ausgeführt, und die Daten werden üblicherweise als JSON übertragen. Ein Kalenderereignis, eine Nachricht, ein Benutzer, eine Gruppe oder eine Datei sind dabei Ressourcen mit Eigenschaften und Beziehungen. Das Microsoft Graph SDK für .NET stellt dafür einen typisierten Client bereit. Anstatt URLs manuell zusammenzubauen und JSON-Antworten selbst zu interpretieren, arbeitet die Anwendung mit Modellen und Request-Buildern.

Für .NET-Projekte ergibt sich daraus ein typischer Aufbau: Die Anwendung verwendet eine Authentifizierungsbibliothek oder einen Credential-Typ, erzeugt daraus einen Graph­ServiceClient und kapselt fachliche Zugriffe in eigenen Services. Ein Projekt könnte beispielsweise einen Calendar­Service, einen MailService und einen DocumentService ­enthalten. Diese Klassen sprechen intern Microsoft Graph an, nach außen liefern sie aber fachliche Methoden wie GetUpcomingCustomerMeetings, SendFollowUpMail oder UploadContractDocument. Dadurch bleibt die Graph-spezifische Logik an einer Stelle gebündelt, und die übrige Anwendung hängt nicht direkt an einzelnen Graph-Endpunkten. Ein Beispiel zeigt das Prinzip:

var scopes = new[] { "User.Read", "Calendars.Read" };
var credential = new InteractiveBrowserCredential(
  new InteractiveBrowserCredentialOptions
  {
    TenantId = tenantId,
    ClientId = clientId
  });

var graphClient = new GraphServiceClient(
  credential, scopes);
var events = await graphClient.Me.Events.GetAsync();

Die Anwendung benötigt eine registrierte App, eine Authentifizierung, passende Berechtigungen und anschließend einen Graph-Client. Für produktive Anwendungen kommen weitere Aspekte hinzu, etwa sichere Konfiguration, Token-Caching, Logging, Fehlerbehandlung und saubere Trennung zwischen Infrastruktur- und Fachlogik. Der Graph Explorer kann als Werkzeug zum Testen von Abfragen und zur Analyse von Request und Response genutzt werden (Bild 3). Microsofts Dokumentation zu Authentifizierung und Autorisierung betont, dass Anwendungen für Microsoft Graph registriert werden, Berechtigungen anfordern und Zugriffstokens erwerben müssen; empfohlen wird dabei der Einsatz von Authentifizierungsbibliotheken, weil sie Details wie Token-Caching und Protokollverarbeitung kapseln.

Die Auswahl des Authentifizierungsflusses hängt stark vom Anwendungstyp ab. Eine Desktop-App kann eine interaktive Anmeldung verwenden. Eine ASP.NET-Core-Web­anwendung nutzt typischerweise die Anmeldung per Mi­cro­soft Identity Platform und arbeitet mit delegierten Berech­tigungen. Ein Hintergrunddienst nutzt dagegen App-only-Zugriff über Client-Secret, Zertifikat oder Managed Identity.

Ein weiteres Grundprinzip ist Pagination. Viele Graph-Abfragen liefern Ergebnisse seitenweise zurück. Wer Benutzer, Nachrichten, Dateien oder Kalenderereignisse abruft, darf nicht davon ausgehen, dass alle Daten in einer einzigen Antwort enthalten sind. Stattdessen muss die Anwendung Folgeseiten verarbeiten. Das ist besonders wichtig bei Synchronisations-Szenarien. Ein häufiges Muster besteht darin, die erste Antwort zu lesen, die enthaltenen Elemente zu verarbeiten und anschließend so lange der nächsten Seite zu folgen, bis kein weiterer Link mehr vorhanden ist. Für wiederkehrende Synchronisationen sind Delta Queries ein zentrales Konzept. Statt bei jedem Lauf alle Daten erneut zu lesen, kann ­eine Anwendung Änderungen an bestimmten Ressourcen nachverfolgen. Microsoft beschreibt Delta Query als Change Tracking, mit dem Anwendungen neu erstellte, geänderte oder gelöschte Entitäten erkennen können, ohne bei jeder Ausführung den vollständigen Bestand erneut abzurufen. Ein typisches Beispiel ist ein lokaler Cache für Kalenderereignisse oder Dateien. Beim ersten Lauf wird der Ausgangsbestand gelesen, anschließend speichert die Anwendung einen Delta-Link. Bei späteren Läufen werden nur noch Änderungen abgefragt. Das reduziert Last, beschleunigt Synchronisationen und verbessert die Skalierbarkeit.

Change Notifications ermöglichen es, ereignisorientierte Architekturen aufzubauen. Eine Anwendung kann sich über Änderungen informieren lassen, etwa wenn neue Nachrichten eintreffen oder Dateien geändert werden. In der Praxis werden Change Notifications und Delta Queries häufig kombiniert: Die Notification signalisiert, dass sich etwas geändert hat; die Anwendung verwendet anschließend eine gezielte Abfrage oder Delta Query, um den tatsächlichen Zustand konsistent zu ermitteln.

Auch Fehlerbehandlung gehört zur Architektur. Graph-Aufrufe können aus vielen Gründen fehlschlagen: fehlende Berechtigungen, abgelaufene Tokens, nicht vorhandene Ressourcen, ungültige Filter, Netzwerkprobleme oder temporäre Dienststörungen. Eine produktive Anwendung sollte diese Fälle unterscheiden. Ein 403 Forbidden weist meist auf ein Berechtigungsproblem hin, ein Fehlercode 404 Not Found auf eine nicht vorhandene oder nicht zugängliche Ressource und ein 429 Too Many Requests auf Drosselung. Besonders bei Hintergrundprozessen ist eine Retry-Strategie wichtig. Gleichzeitig darf nicht jeder Fehler blind wiederholt werden. Berechtigungsfehler lösen sich durch Wiederholung nicht, temporäre Netzwerkfehler dagegen häufig schon.

Sicherheit, Berechtigungen und Governance

Microsoft Graph ist so attraktiv, weil das API zentrale Microsoft-365-Daten über ein einheitliches Modell zugänglich macht. Genau daraus entsteht aber auch die größte Verantwortung. Wer Graph in eine Anwendung integriert, öffnet potenziell den Zugriff auf Benutzerprofile, Kalender, E-Mails, Dateien, Teams, Gruppen, SharePoint-Sites und Organisationsdaten. Das sind häufig personenbezogene, vertrauliche oder geschäftskritische Informationen. Sicherheit ist deshalb kein nachgelagerter Aspekt, sondern ein zentrales Architekturthema.

Microsoft Graph kennt grundsätzlich zwei Berechtigungsmodelle: delegierte Berechtigungen und Anwendungsberechtigungen. Delegierte Berechtigungen werden verwendet, wenn eine Anwendung im Namen eines angemeldeten Benutzers arbeitet. Die Anwendung kann dann nur auf Daten zugreifen, auf die auch dieser Benutzer zugreifen darf. Ein Beispiel: Eine Blazor-Anwendung zeigt dem angemeldeten Benutzer seine nächsten Termine an. Sie benötigt dafür eine passende Kalenderberechtigung, arbeitet aber weiterhin im Kontext dieses Benutzers. Hat der Benutzer keinen Zugriff auf den Kalender eines Kollegen, darf auch die Anwendung diesen Kalender nicht lesen.

Anwendungsberechtigungen funktionieren anders. Sie erlauben einer Anwendung den Zugriff ohne angemeldeten Benutzer. Microsoft beschreibt diese Berechtigungen auch als App Roles beziehungsweise App-only-Zugriff. Ein Synchronisationsdienst, der Dokumente aus einer SharePoint-­Bibliothek ausliest, kann nicht auf eine interaktive Benutzeranmeldung angewiesen sein.

In der Praxis beginnt ein sicheres Graph-Design mit dem Prinzip der minimalen Rechte. Eine Anwendung sollte nur die Berechtigungen anfordern, die sie für ihre konkrete Aufgabe wirklich benötigt. Wer nur das Profil des angemeldeten Benutzers lesen möchte, sollte nicht mandantenweite Benutzerberechtigungen anfordern. Wer nur Kalendereinträge lesen muss, benötigt keine Schreibrechte. Wer eine Datei hochladen soll, braucht nicht automatisch Zugriff auf alle Dateien im Tenant.

Während der Entwicklung ist es verlockend, pauschal umfassende Scopes zu verwenden, damit erste Prototypen schnell funktionieren. Später bleiben diese Rechte dann oft unverändert in der App-Registrierung stehen. Aus einem einfachen Kalenderfeature wird so schnell eine Anwendung mit unnötigem Zugriff auf E-Mails, Dateien oder Benutzerlisten. Besser ist ein iterativer, aber kontrollierter Ansatz: Für jedes Feature wird festgelegt, welche Graph-Ressourcen benötigt werden, welche Operationen ausgeführt werden und welche minimale Berechtigung dafür ausreicht. Diese Entscheidung sollte im Code, in der Architektur- oder Betriebsdokumen­tation nachvollziehbar sein. Die Namen der Graph-Berech­tigungen folgen einem wiederkehrenden Muster. Häufig ­bestehen sie aus Ressource, Operation und Reichweite, etwa User.Read, Calendars.Read, Mail.Read, Files.Read.All oder Sites.Read.All.

Die Anwendung muss in Microsoft Entra ID registriert sein, die benötigten Berechtigungen anfordern und dafür eine Zustimmung erhalten. Eine Anwendung, die nur im eigenen Entwicklungsmandanten getestet wird, lässt sich meist schnell zum Laufen bringen. In einem Kundenmandanten oder produktiven Unternehmensumfeld ist der Prozess dagegen deutlich formaler. Administratoren wollen wissen, welche Daten gelesen oder geschrieben werden, warum diese Berechtigungen nötig sind, ob es Alternativen mit geringerem Zugriff gibt und wie die Anwendung betrieben wird. Deshalb sollte eine Graph-basierte Lösung früh eine klare Berechtigungsmatrix erhalten.

App-only-Szenarien eignen sich für Automatisierung, Synchronisation und Systemintegration, sollten aber restriktiv geplant werden. Da der Zugriff nicht durch die Rechte eines aktuell angemeldeten Benutzers begrenzt wird, sind administrative Freigabe, klare Verantwortlichkeiten und regel­mäßige Berechtigungsprüfungen besonders wichtig.

Aus Entwicklersicht sollte man prüfen, ob wirklich mandantenweite Rechte erforderlich sind oder ob sich der Zugriff einschränken lässt.

Ein weiterer Baustein sicherer Graph-Anwendungen ist die Verwaltung von Geheimnissen und Anmeldeinformationen. In frühen Beispielen sieht man häufig Client-Secrets in Konfigurationsdateien oder lokalen Einstellungen. Für produk­tive Systeme ist das riskant. Geheimnisse sollten nicht im Quellcode, nicht in Repositories und nicht ungeschützt in Konfigurationen liegen. Für Azure-basierte Anwendungen sind Managed Identities besonders interessant, weil sie den Zugriff auf andere Ressourcen ermöglichen, ohne dass die Anwendung selbst dauerhafte Secrets verwalten muss. Managed Identities sind ein Ersatz für Geheimnisse wie Zugriffsschlüssel oder Kennwörter. Auch Zertifikate und andere ­Authentifizierungsformen können in bestimmten Service-to-Service-Szenarien dadurch ersetzt werden (vergleiche Kasten Managed Identities).

Managed Identities

Managed Identities sind von Azure verwaltete Identitäten, mit denen sich Anwendungen gegenüber Azure-Diensten authentifizieren können, ohne Passwörter, Client-Secrets oder Zertifikate im Code oder in Konfigurationsdateien zu speichern. Die Identität wird direkt an eine Azure-Ressource wie eine Azure-App-Service-App, Azure Function oder virtuelle Maschine gebunden. Dadurch können Anwendungen sicher auf Dienste wie Key Vault, Storage oder Microsoft Graph zugreifen, während Azure die Verwaltung der Anmeldeinformationen übernimmt.

Wenn Managed Identities nicht infrage kommen, sind Zertifikate häufig eine robustere Alternative zu Client-Secrets. Zertifikate basieren auf asymmetrischer Kryptografie; nur der Besitzer des privaten Schlüssels kann sich authentifizieren. Auch Tokens verdienen Aufmerksamkeit. Zugriffstokens sind sensible Daten. Sie sollten nicht geloggt, nicht im Browser unnötig gespeichert und nicht an nicht vertrauenswürdige Komponenten weitergegeben werden. In Webanwendungen ist sorgfältig zu entscheiden, ob Graph-Aufrufe direkt aus dem Frontend erfolgen oder über ein Backend vermittelt werden. Häufig ist ein Backend-for-Frontend-Ansatz sicherer, weil Token-Verarbeitung, Graph-Zugriff und Fehler­behandlung serverseitig kontrolliert werden können. Bei ­Single Page Applications oder Blazor-WebAssembly-Anwendungen muss dagegen besonders auf Token-Lebens­dauer, Speicherort und API-Grenzen geachtet werden.

Sicherheit endet nicht beim technischen Zugriff. Governance sorgt dafür, dass App-Registrierungen, Secrets, Berechtigungen und Integrationen dauerhaft nachvollziehbar, überprüfbar und verantwortet bleiben. Eine gute Praxis ist daher, App-Registrierungen eindeutig zu benennen, Verantwortliche zu hinterlegen, Berechtigungen regelmäßig zu überprüfen und nicht mehr benötigte Anwendungen oder ­Secrets zu entfernen. Für produktive Anwendungen ist ­außerdem ein Monitoring wichtig. Graph-Zugriffe sollten so protokolliert werden, dass technische Fehler und sicherheitsrelevante Ereignisse nachvollziehbar sind, ohne vertrauliche Inhalte preiszugeben. In Logs gehören keine Zugriffstokens, keine vollständigen E-Mail-Inhalte und keine sensiblen Dokumentdaten. Sinnvoll sind dagegen Informationen wie Korrelations-IDs, Zeitpunkte, technische Fehlercodes, betroffene Featurebereiche und Dauer von Aufrufen. Für Entwickler entsteht daraus eine klare Leitlinie: Microsoft Graph sollte immer vom Sicherheitsmodell her mitentworfen werden.

Business-Szenarien mit Microsoft Graph

Microsoft Graph wird für Entwickler vor allem dann interessant, wenn mehrere Microsoft-365-Ressourcen zu einem konkreten Geschäftsprozess verbunden werden. Outlook, Teams, OneDrive, SharePoint, Kalender und Microsoft-365-Gruppen bilden in vielen Unternehmen bereits den organisatorischen Rahmen für Kommunikation, Zusammenarbeit und Dokumentenmanagement. Graph macht diesen Arbeitskontext für eigene .NET-Anwendungen nutzbar. Statt parallele Funktionen für Termine, E-Mails, Dateien oder Benutzerverwaltung neu zu entwickeln, können Anwendungen vorhandene Microsoft-365-Strukturen gezielt einbinden.

Ein erstes typisches Szenario ist die Vorbereitung und Durchführung von Kundenworkshops. Ein Projektleiter legt in einer internen Fachanwendung einen Workshop an. Die Anwendung prüft über Microsoft Graph die Verfügbarkeit der vorgesehenen Teilnehmer, schlägt geeignete Zeitfenster vor und erstellt nach Auswahl des Termins automatisch einen Kalendereintrag. Bei Bedarf wird zusätzlich ein Teams-Meeting erzeugt. Ergänzend kann die Anwendung relevante Share­Point-Dokumente zum Kundenprojekt anzeigen, vorhandene Protokolle verlinken oder eine Follow-up-Mail vorbereiten. Für den Benutzer entsteht ein durchgängiger Ablauf: Er bleibt in der Fachanwendung, während Termine, Kommunikation und Dokumente dort abgelegt werden, wo sie im Unternehmen ohnehin genutzt werden. Die Fach­anwendung steuert den Prozess, Microsoft 365 übernimmt Kalender, Besprechung, Dokumente und Kommunikation.

Aus Entwicklersicht zeigt dieses Beispiel, dass Graph-Zugriffe nicht direkt im UI-Code landen sollten. Sinnvoller ist ­eine eigene Integrationsschicht, etwa mit Services wie IMeetingScheduler, IDocumentRepository oder IMailComposer. Diese kapseln die konkrete Graph-Kommunikation und stellen fachliche Methoden bereit, beispielsweise FindAvailableSlots, CreateWorkshopMeeting, LoadProjectDocuments oder PrepareFollowUpMail. Dadurch bleibt die Anwendung besser testbar und wartbar. Außerdem lassen sich Berechtigungen, Fehlerbehandlung, Logging und spätere Änderungen an dem Graph-API zentral behandeln.

Ein zweites mögliches Szenario ist ein automatisierter Dokumentenworkflow mit SharePoint. Viele Geschäftsprozesse erzeugen oder verarbeiten Dateien: Angebote, Verträge, Prüf­berichte, Spezifikationen oder Protokolle. Eine .NET-Anwendung muss dafür nicht zwangsläufig ein eigenes Dokumentenarchiv aufbauen. Sie kann SharePoint oder OneDrive als Dokumentenplattform nutzen und über Microsoft Graph Dateien hochladen, herunterladen, Metadaten lesen oder Änderungen verfolgen. Ein Vertragsmanagementsystem könnte zum Beispiel den eigentlichen Vertragsdatensatz in der eigenen Datenbank halten, das Vertragsdokument aber in einer Share­Point-Bibliothek speichern. Beim Anlegen eines Vertrags erzeugt die Anwendung eine passende Ordnerstruktur, legt Vorlagen ab und berücksichtigt später Versionen oder Freigaben.

Für automatisierte Verarbeitung sind Delta Queries und Change Notifica­tions besonders wichtig. Eine Azure Function kann beispielsweise informiert werden, wenn in einer Share­Point-Bibliothek eine neue Datei abgelegt oder geändert wurde. Der Webhook sollte die Verarbeitung jedoch nicht vollständig selbst durchführen, sondern nur einen Auftrag in eine Queue legen. Ein Worker liest anschließend die Datei über Microsoft Graph, extrahiert Metadaten, prüft formale Kriterien und schreibt das Ergebnis in ein internes System. Delta Queries helfen zusätzlich dabei, Änderungen seit dem letzten Verarbeitungslauf effizient zu erkennen, ohne regelmäßig große Datenbestände vollständig neu abzufragen. So entstehen skalierbare und robuste Architekturen, die besser mit großen Dokumentenmengen umgehen können.

Auch Outlook- und Mailprozesse lassen sich in ähnliche Szenarien integrieren. Ein Supportsystem kann neue Nachrichten aus einem Funktionspostfach auslesen, Anhänge einem Ticket zuordnen und eine Eingangsbestätigung vorbereiten. Eine Vertriebsanwendung kann nach einem Kunden­termin eine Follow-up-Mail mit Link auf ein SharePoint-Protokoll erzeugen. Wichtig ist dabei, nicht jede Automatisierung sofort vollständig autonom auszuführen. Häufig ist es fachlich sinnvoller, E-Mails vorzubereiten, Vorschläge zu machen oder Inhalte zu klassifizieren, während der Benutzer die finale Entscheidung trifft.

Bei allen Szenarien sollte nicht der verfügbare API-Endpunkt, sondern der fachliche Prozess den Entwurf bestimmen. Zuerst wird geklärt, welche Aufgabe vereinfacht oder automatisiert werden soll. Danach werden die benötigten Microsoft-365-Ressourcen identifiziert: Kalender, Nachrichten, Da­teien, Benutzer, Gruppen, Teams oder SharePoint-Sites. Erst anschließend folgen Berechtigungsmodell, Authentifizierung, SDK-Nutzung, Webhooks, Delta Queries oder Retry-Strategien. Diese Reihenfolge verhindert, dass eine Lösung von zufällig verfügbaren API-Funktionen getrieben wird statt vom eigentlichen Nutzen.

Der größte Wert von Microsoft Graph entsteht dort, wo mehrere Microsoft-365-Dienste zusammenspielen. Ein einzelner Kalenderaufruf ist hilfreich, aber noch keine Connected App. Spannend wird es, wenn Kalender, E-Mail, Dokumente, Teams und Identität zu einem fachlichen Ablauf verbunden werden. Dann entstehen Anwendungen, die Medienbrüche reduzieren, Prozesse automatisieren und Benutzer in ihrem vorhandenen Arbeitsumfeld unterstützen. Für .NET-Entwickler ist Microsoft Graph damit weniger ein ­zusätzlicher Datenzugriff als vielmehr ein Integrationsmodell für moderne Business-Anwendungen im Microsoft-Ökosystem.

Microsoft Graph als Grundlage intelligenter Anwendungen

Microsoft Graph ist nicht nur eine ­In­tegrationsschnittstelle für Kalender, ­E-Mails, Dateien und Benutzerinformationen. Das API liefert vor allem Kontext. Genau dieser Kontext ist die Grundlage für intelligente Anwendungen. Ein Sprachmodell kann Texte ­erzeugen, Fragen beantworten oder Informationen zusammenfassen. Für eine nützliche Business-Anwendung reicht das jedoch nicht aus. Sie muss wissen, auf welche Daten ein Benutzer zugreifen darf, welche Dokumente zu einem Vorgang gehören, welche Termine anstehen, welche Personen beteiligt sind und welche Kommunika­tion zuletzt stattgefunden hat. Microsoft Graph kann diese Informationen aus dem Microsoft-365-Ökosystem erschließen und damit die Brücke zwischen generativer KI und konkretem Arbeitskontext schlagen.

Ein Beispiel ist die Vorbereitung eines Kundentermins. Eine .NET-Anwendung könnte über Microsoft Graph die nächsten Kalendertermine des angemeldeten Benutzers lesen, Teilnehmerinformationen ergänzen, relevante E-Mails zum Kunden abrufen und Dokumente aus einem SharePoint-Projektbereich berücksichtigen. Anschließend erstellt ein KI-Modell daraus eine kompakte Vorbereitung: offene Punkte, zuletzt besprochene Themen, relevante Dokumente, Risiken und mögliche nächste Schritte. Der Benutzer erhält keine generische KI-Antwort, sondern eine kontextbezogene Arbeitsunterstützung. Entscheidend ist dabei, dass die Anwendung nicht mehr Informationen verwendet, als der Benutzer sehen darf. Graph liefert damit nicht nur Daten, sondern auch den berechtigten Nutzungskontext, in dem diese Daten verarbeitet werden dürfen.

Besonders relevant wird Retrieval-Augmented Generation, kurz RAG. RAG beschreibt ein Muster, bei dem ein Sprachmodell seine Antwort nicht nur aus dem trainierten Modellwissen erzeugt, sondern diese Antwort aus zusätzlich abgerufenen, relevanten Unternehmensdaten ermittelt. Eine RAG-Architektur mit Microsoft Graph und .NET kann folgendermaßen aussehen: Ein Hintergrundprozess liest über Graph ausgewählte Dokumente aus SharePoint oder OneDrive, zerlegt sie in kleinere Abschnitte, erzeugt Embeddings und speichert diese in einem Suchindex, beispielsweise in Azure AI Search (Bild 4). Bei einer Benutzerfrage wird zunächst der relevante Kontext aus dem Index gesucht. Erst danach wird das Sprachmodell mit Frage und gefundenen Textpassagen aufgerufen. Die Antwort kann mit Quellenhinweisen versehen und in der Anwendung angezeigt werden. Eine robuste Architektur trennt mehrere Aufgaben: Graph-Zugriff, Berechtigungsprüfung, Datenaufbereitung, Indexierung, Retrieval, Prompt-Erzeugung, Modellaufruf und Ergebnisdarstellung.

Ein weiteres Beispiel ist ein interner Wissensassistent für Projektteams. In vielen Unternehmen liegen Informationen verteilt über SharePoint-Bibliotheken, Teams-Kanäle, Besprechungsnotizen, E-Mail-Verläufe und persönliche OneDrive-Ordner. Ein Mitarbeiter fragt etwa: „Welche offenen Punkte wurden im letzten Lenkungskreis zum Projekt Alpha beschlossen?“ Die Anwendung durchsucht nicht wahllos ­alle Unternehmensdaten, sondern ermittelt zunächst den relevanten Projektkontext und prüft die Zugriffsrechte des Benutzers. Anschließend werden passende Protokolle, Präsentationen oder E-Mail-Zusammenfassungen über Graph erschlossen und für die KI-Auswertung vorbereitet. Das Modell erzeugt daraus eine Antwort mit Verweisen auf die zugrunde liegenden Quellen. Der Benutzer erhält damit keine isolierte Textgenerierung, sondern eine nachvollziehbare Recherchehilfe im eigenen Arbeitskontext.

Solche Szenarien zeigen: Intelligente Anwendungen bestehen nicht allein aus dem Sprachmodell. Entscheidend ist die kontrollierte Orchestrierung von Datenzugriff, Berechtigungsprüfung, Suche, Prompt-Erzeugung und Ergebnis­darstellung. Graph liefert die Verbindung zu Microsoft 365, Azure AI Search übernimmt beispielsweise die semantische Suche, und ein Sprachmodell formuliert daraus eine verständliche Antwort. Die .NET-Anwendung hält diese Bausteine zusammen und entscheidet, welche Daten gelesen, welche Inhalte verarbeitet und welche Ergebnisse dem Benutzer angezeigt werden. Gerade bei Unternehmensdaten ist diese Kontrollschicht unverzichtbar, damit KI-Funktionen nachvollziehbar bleiben und keine Informationen preisgeben, auf die der Benutzer anderweitig keinen Zugriff hat.

Für produktive Szenarien empfiehlt sich außerdem ein ­Human-in-the-Loop-Ansatz. Eine KI kann E-Mails zusammenfassen, Antwortentwürfe erzeugen, Risiken in Dokumenten markieren oder Aufgaben aus Besprechungsnotizen ableiten. Kritische Aktionen wie das Versenden einer Mail, das Ändern eines Termins oder das Freigeben eines Dokuments sollten jedoch bewusst durch den Benutzer bestätigt werden. So bleibt die Anwendung hilfreich, ohne unkontrolliert in Geschäftsprozesse einzugreifen. Microsoft Graph liefert dafür den Kontext und die Verbindung zu den Arbeitsdaten; die .NET-Anwendung sorgt für Sicherheit, Nachvollziehbarkeit und fachliche Kontrolle.

Fazit und Ausblick

Microsoft Graph vereinheitlicht den Zugriff auf Microsoft-365-Daten, ersetzt aber nicht die fachliche, sicherheitstechnische und betriebliche Gestaltung der Anwendung. Für .NET-Entwickler ist es deshalb wichtig, Microsoft Graph nicht als einfaches Komfort-API zu betrachten, sondern als produktions­relevante Schnittstelle zu geschäftskritischen Diensten. Eine robuste Graph-Anwendung entsteht nicht allein durch funktionierende Requests. Entscheidend sind minimale Berechtigungen, tragfähige Architekturentscheidungen, performante Abfragen, klare Governance und zuverlässiger Betrieb. Das API ermöglicht es, vorhandene Microsoft-365-Dienste nicht nur zu konsumieren, sondern fachlich sinnvoll in eigene Anwendungen einzubetten. Die eigene Lösung muss nicht alle Kommunikations-, Kalender-, Datei- und Identitätsfunktionen neu erfinden. Sie kann auf Microsoft 365 aufbauen und sich auf den eigentlichen Geschäftsprozess konzentrieren. Damit wird Graph besonders dort interessant, wo Anwendungen Arbeitsabläufe vereinfachen, Medienbrüche reduzieren und Benutzern kontextbezogene Unterstützung bieten sollen.◾