Microsoft Entra ID App-Registrierung: Ein Leitfaden für die korrekte Plattformkonfiguration

In der heutigen digitalisierten Welt sind Anwendungen das Herzstück fast jedes Unternehmens. Ob es sich um eine interne Webanwendung, eine mobile Kunden-App oder einen Backend-Dienst handelt – sie alle benötigen eine sichere Möglichkeit, auf Ressourcen zuzugreifen und Benutzer zu authentifizieren. Hier kommt die Microsoft Entra ID App-Registrierung ins Spiel. Als zentraler Baustein für Identitäts- und Zugriffsmanagement in der Microsoft Cloud ermöglicht sie es Anwendungen, sicher mit Microsoft Entra ID (ehemals Azure Active Directory) zu interagieren.

Doch eine App-Registrierung ist weit mehr als nur ein Eintrag in einem Verzeichnis. Ihre Plattformkonfiguration ist entscheidend für die Sicherheit, Funktionalität und Kompatibilität Ihrer Anwendung. Eine fehlerhafte Konfiguration kann zu Sicherheitslücken, Funktionsstörungen oder gar dazu führen, dass Ihre Anwendung überhaupt nicht funktioniert. Dieser umfassende Leitfaden führt Sie durch die Komplexität der Plattformkonfiguration, erklärt die verschiedenen Optionen und zeigt Ihnen, wie Sie Ihre Anwendungen korrekt und sicher in Microsoft Entra ID integrieren.

Was ist eine App-Registrierung und warum ist sie so wichtig?

Stellen Sie sich eine App-Registrierung als die „Identität” Ihrer Anwendung innerhalb von Microsoft Entra ID vor. Sie ist der Prozess, bei dem Sie Ihrer Anwendung erlauben, sich bei Microsoft Entra ID zu authentifizieren und im Namen von Benutzern (oder sich selbst) Zugriffstokens anzufordern. Diese Tokens sind der Schlüssel, um auf geschützte Ressourcen wie Microsoft Graph, benutzerdefinierte APIs oder andere Azure-Dienste zuzugreifen.

Die App-Registrierung in Microsoft Entra ID erfüllt mehrere grundlegende Zwecke:

• Authentifizierung: Sie ermöglicht es Benutzern, sich bei Ihrer Anwendung anzumelden, indem sie ihre Entra ID-Anmeldeinformationen verwenden.
• Autorisierung: Sie definiert, welche Berechtigungen Ihre Anwendung für den Zugriff auf APIs und Daten hat.
• Vertrauensstellung: Sie etabliert eine Vertrauensbeziehung zwischen Ihrer Anwendung und Microsoft Entra ID, die für den sicheren Austausch von Tokens unerlässlich ist.

Ohne eine korrekte App-Registrierung kann Ihre Anwendung weder Benutzer authentifizieren noch sicher auf die benötigten Ressourcen zugreifen. Es ist der Grundstein für jede Anwendung, die mit dem Microsoft Cloud-Ökosystem interagiert.

Microsoft Entra ID vs. Azure Active Directory: Eine kurze Klarstellung

Bevor wir tiefer in die Konfiguration eintauchen, ist es wichtig, eine kleine, aber bedeutsame Namensänderung zu klären. Das, was viele als Azure Active Directory (Azure AD) kannten, wurde im Juli 2023 offiziell in Microsoft Entra ID umbenannt. Dies ist Teil einer breiteren Umbenennung des Microsoft Entra-Produktfamilie, die alle Identitäts- und Zugriffsmanagementlösungen von Microsoft unter einem Dach vereint. Die Funktionalität und die zugrunde liegende Architektur für App-Registrierungen bleiben dieselben, lediglich der Name hat sich geändert. Wenn Sie also von „Azure AD App-Registrierung” hören, ist „Microsoft Entra ID App-Registrierung” gemeint.

Die entscheidende Rolle der Plattformkonfiguration

Die Plattformkonfiguration ist der Kernbereich, in dem Sie Microsoft Entra ID mitteilen, welche Art von Anwendung Sie entwickeln und wie diese mit dem Authentifizierungsdienst interagieren soll. Dies beinhaltet insbesondere die Definition von Umleitungs-URIs (Redirect URIs) und die Auswahl der geeigneten Authentifizierungsmethoden. Eine präzise Konfiguration ist aus mehreren Gründen unerlässlich:

• Sicherheit: Falsch konfigurierte Umleitungs-URIs können zu Open Redirect Vulnerabilities führen, bei denen Angreifer Tokens abfangen können.
• Funktionalität: Die richtige Konfiguration stellt sicher, dass Ihre Anwendung die notwendigen Tokens erhält und korrekt mit Benutzern und APIs kommuniziert.
• Benutzererfahrung: Eine reibungslose Authentifizierung ohne Fehler verbessert die Akzeptanz Ihrer Anwendung.
• Compliance: Viele Sicherheitsstandards erfordern eine genaue Definition und Überprüfung von Zugriffspunkten und -methoden.

Schritt-für-Schritt: Eine App-Registrierung erstellen

Bevor wir uns den Details der Plattformkonfiguration widmen, hier die grundlegenden Schritte zur Erstellung einer App-Registrierung:

1. Anmelden im Azure-Portal: Navigieren Sie zu portal.azure.com und melden Sie sich mit einem Konto an, das über ausreichende Berechtigungen verfügt (z.B. Anwendungsentwickler oder globaler Administrator).
2. Microsoft Entra ID aufrufen: Suchen Sie im Suchfeld nach „Microsoft Entra ID” und wählen Sie den Dienst aus.
3. App-Registrierungen navigieren: Wählen Sie im linken Navigationsbereich unter „Verwalten” die Option „App-Registrierungen” aus.
4. Neue Registrierung: Klicken Sie auf „Neue Registrierung”.
5. Anwendungsnamen festlegen: Geben Sie einen aussagekräftigen Namen für Ihre Anwendung ein (z.B. „Meine Web-App für Kundenportal”).
6. Unterstützte Kontotypen auswählen:
   • Nur Konten in diesem Organisationsverzeichnis (Single-Tenant): Für Anwendungen, die nur von Benutzern in Ihrem Entra ID-Mandanten verwendet werden.
   • Konten in jedem Organisationsverzeichnis (Multi-Tenant): Für Anwendungen, die von Benutzern in verschiedenen Entra ID-Mandanten verwendet werden können.
   • Konten in beliebigen Organisationsverzeichnissen und persönliche Microsoft-Konten: Für Anwendungen, die sowohl Geschäftsbenutzer als auch private Microsoft-Konten (outlook.com, hotmail.com) unterstützen.

   Die Auswahl hier ist entscheidend und kann später nicht direkt geändert werden; bei Bedarf müsste die App neu registriert werden.

7. (Optional) Umleitungs-URI hinzufügen: Sie können hier bereits einen ersten Umleitungs-URI hinzufügen. Wir werden dies jedoch im nächsten Abschnitt detaillierter behandeln.
8. Registrieren: Klicken Sie auf „Registrieren”, um die Basis-App-Registrierung zu erstellen.

Nach der Registrierung landen Sie auf der Übersichtsseite Ihrer Anwendung. Hier finden Sie wichtige Informationen wie die Anwendungs-ID (Client-ID) und die Verzeichnis-ID (Mandanten-ID), die Ihre Anwendung für die Kommunikation mit Entra ID benötigt.

Der tiefe Einblick: Plattformkonfiguration im Detail

Nachdem die App-Registrierung erstellt wurde, navigieren Sie im linken Menü der App-Registrierung zu „Authentifizierung”. Hier nehmen Sie die entscheidenden Plattformkonfigurationen vor.

1. Web-Anwendungen (ASP.NET, Java, Node.js-basierte Web-Apps)

Web-Anwendungen sind serverseitige Anwendungen, die in einem Browser ausgeführt werden und Benutzer über eine dedizierte Anmeldeseite authentifizieren. Der Autorisierungscode-Flow mit PKCE (Proof Key for Code Exchange) ist hier der empfohlene Standard.

• Umleitungs-URIs (Redirect URIs): Dies sind die URLs, an die Microsoft Entra ID das Sicherheitstoken zurücksendet, nachdem ein Benutzer erfolgreich authentifiziert wurde.
  • Format: Muss immer mit https:// beginnen (außer für localhost-Entwicklung).
  • Beispiele: https://localhost:5001/signin-oidc (für Entwicklung), https://meineapp.com/auth-callback.
  • Best Practice: Seien Sie so spezifisch wie möglich. Vermeiden Sie Wildcards wie https://*.meineapp.com, wenn es nicht unbedingt notwendig ist, da diese das Risiko von Open Redirects erhöhen können. Fügen Sie nur die URIs hinzu, die Ihre Anwendung tatsächlich verwendet.
  • Front-Channel Logout URL: Optional, aber nützlich. Wenn konfiguriert, sendet Entra ID eine Anfrage an diese URL, wenn sich ein Benutzer von einem anderen Konto abmeldet, was Ihrer Anwendung ermöglicht, ihre Sitzung ebenfalls zu beenden.
• Implizite Genehmigung und Hybrid-Flow:
  • ID-Tokens (impliziter Flow): Ermöglicht der Anwendung, ID-Tokens direkt aus dem Autorisierungs-Endpunkt zu erhalten. Historisch für SPAs verwendet, aber für moderne Web-Apps durch den Auth Code Flow + PKCE überholt.
  • Zugriffstoken (impliziter Flow): Ermöglicht der Anwendung, Zugriffstoken direkt aus dem Autorisierungs-Endpunkt zu erhalten. Aus Sicherheitsgründen für Web-Anwendungen nicht empfohlen.

  Empfehlung für Web-Apps: In den meisten modernen Web-Anwendungen, die den Autorisierungscode-Flow nutzen, sollten Sie die Optionen für „Implizite Genehmigung und Hybrid-Flow” (also ID-Tokens und Zugriffstoken) nicht aktivieren. Der Auth Code Flow mit einem sicheren Backend für den Token-Austausch ist sicherer.

2. Single-Page Applications (SPAs) (React, Angular, Vue.js)

SPAs laufen vollständig im Browser des Benutzers. Hier hat sich in den letzten Jahren ein großer Wandel vollzogen.

• Umleitungs-URIs:
  • Format: Oft mit Hash-Fragmenten (#) oder Pfaden. Beispiel: https://meinespa.com/callback.
  • Best Practice: Verwenden Sie hier ebenfalls https://. Für Entwicklung ist http://localhost:port zulässig.
• Implizite Genehmigung und Hybrid-Flow:
  • Historisch: SPAs verwendeten traditionell den impliziten Flow, um ID-Tokens und Zugriffstoken direkt im Browser zu erhalten. Diese Optionen finden Sie hier.
  • Moderne Empfehlung: Für neue SPAs wird dringend der Autorisierungscode-Flow mit PKCE empfohlen. Dieser ist sicherer, da keine Tokens direkt über die URL übergeben werden und das Zugriffstoken im Hintergrund über einen sicheren Token-Endpunkt abgerufen wird. Wenn Sie den Auth Code Flow + PKCE verwenden, sollten Sie „ID-Tokens” und „Zugriffstoken” hier nicht aktivieren.

3. Mobile und Desktop-Anwendungen (iOS, Android, WPF, UWP)

Diese Anwendungen laufen auf einem Gerät des Benutzers und sind als „öffentliche Clients” klassifiziert, da sie keine Client-Geheimnisse sicher speichern können.

• Umleitungs-URIs:
  • Mobile: Oft benutzerdefinierte URI-Schemata (z.B. msauth://com.meinefirma.app/xxxx für Microsoft Authenticator) oder Deep Links.
  • Desktop: Loopback-Adresse (http://localhost oder http://localhost/ gefolgt von einem spezifischen Port). Entra ID kann auch den integrierten Systembrowser verwenden, der eine Umleitung zu msal{client-id}://auth verwendet.
• Empfehlung: Für mobile und Desktop-Anwendungen ist der Autorisierungscode-Flow mit PKCE der Standard und wird dringend empfohlen. Aktivieren Sie die Option „Öffentlicher Client (mobil & Desktop)” unter „Authentifizierungstypen”, um diese Anwendungen als öffentliche Clients zu kennzeichnen. Dadurch können sie den PKCE-Flow nutzen, ohne ein Client-Geheimnis zu benötigen.

4. Andere Plattformen (z.B. Daemon-Anwendungen, Dienste, APIs)

Anwendungen, die ohne interaktivem Benutzer arbeiten (z.B. Backend-Dienste, geplante Tasks), verwenden oft den Client-Anmeldeinformations-Flow (Client Credentials Flow).

• Keine Umleitungs-URIs: Da diese Anwendungen nicht interaktiv sind und keine Benutzer zum Anmelden weiterleiten, benötigen sie in der Regel keine Umleitungs-URIs.
• Geheimnisse oder Zertifikate: Sie authentifizieren sich direkt bei Microsoft Entra ID mit einem Client-Geheimnis oder einem Zertifikat. Diese werden im Abschnitt „Zertifikate & Geheimnisse” Ihrer App-Registrierung konfiguriert.

Allgemeine Einstellungen & Überlegungen

Neben den plattformspezifischen Einstellungen gibt es weitere wichtige Bereiche in Ihrer App-Registrierung:

• API-Berechtigungen (API Permissions): Hier definieren Sie, auf welche APIs (z.B. Microsoft Graph, Ihre eigenen Web-APIs) Ihre Anwendung zugreifen darf und mit welchen Berechtigungen (delegierte Berechtigungen im Namen eines Benutzers oder Anwendungsberechtigungen als die Anwendung selbst). Wählen Sie hier immer das Prinzip der geringsten Rechte.
• Zertifikate & Geheimnisse (Certificates & Secrets): Wenn Ihre Anwendung den Client Credential Flow oder andere Flows verwendet, die eine geheime Information benötigen, konfigurieren Sie hier Client-Geheimnisse oder Zertifikate. Zertifikate sind aus Sicherheitsgründen gegenüber Client-Geheimnissen zu bevorzugen, da sie schwerer zu kompromittieren sind. Achten Sie auf Ablaufdaten und planen Sie Rotationen.
• Manifest: Über das Anwendungsmanifest können Sie fortgeschrittene Einstellungen vornehmen, die über die UI nicht verfügbar sind, z.B. das Hinzufügen von optionalen Ansprüchen (Optional Claims) in Tokens.

Best Practices und Sicherheitsüberlegungen

Die korrekte Plattformkonfiguration ist ein Pfeiler der Sicherheit. Beachten Sie folgende Best Practices:

1. Immer HTTPS für Umleitungs-URIs: Eine der wichtigsten Regeln. Verwenden Sie niemals HTTP für Produktions-Umleitungs-URIs (außer für localhost während der Entwicklung).
2. Umleitungs-URIs genau definieren: Listen Sie nur die absolut notwendigen URIs auf. Vermeiden Sie Wildcards, wo immer möglich. Jeder zusätzliche URI ist ein potenzieller Angriffspunkt.
3. Verwenden Sie den Autorisierungscode-Flow mit PKCE: Für öffentliche Clients (SPAs, Mobile, Desktop) ist dies der sicherste und modernste Ansatz. Vermeiden Sie den impliziten Flow, wenn es nicht aus Kompatibilitätsgründen mit älteren Frameworks unbedingt notwendig ist.
4. Das Prinzip der geringsten Rechte (Least Privilege) anwenden: Gewähren Sie Ihrer Anwendung nur die API-Berechtigungen, die sie unbedingt benötigt, und nicht mehr. Überprüfen Sie regelmäßig die zugewiesenen Berechtigungen.
5. Sichere Verwaltung von Client-Geheimnissen/Zertifikaten:
   • Client-Geheimnisse: Niemals im Code hart codieren. Verwenden Sie sichere Konfigurationsspeicher wie Azure Key Vault oder Umgebungsvariablen. Rotieren Sie Geheimnisse regelmäßig (z.B. alle 90 Tage).
   • Zertifikate: Verwenden Sie sie, wenn möglich, anstelle von Geheimnissen. Verwalten Sie private Schlüssel sicher.
6. Mandantenbeschränkungen beachten (Multi-Tenant vs. Single-Tenant): Verstehen Sie die Auswirkungen der gewählten Kontotypen. Wenn Ihre Anwendung nur für Ihr Unternehmen bestimmt ist, verwenden Sie „Nur Konten in diesem Organisationsverzeichnis”.
7. Überwachen und Auditieren: Überprüfen Sie regelmäßig die Anmelde- und Auditprotokolle in Microsoft Entra ID, um ungewöhnliche Aktivitäten im Zusammenhang mit Ihrer Anwendung zu erkennen.
8. Verwenden Sie Managed Identities für Azure-Ressourcen: Wenn Ihre Anwendung in Azure gehostet wird (z.B. Azure App Service, Azure Functions), nutzen Sie Managed Identities. Diese bieten eine automatische, sichere Authentifizierung gegenüber Entra ID-geschützten Ressourcen, ohne dass Sie Client-Geheimnisse manuell verwalten müssen. Dies ist eine extrem sichere und empfohlene Methode.

Häufige Fehler und wie man sie vermeidet

• Falscher Umleitungs-URI: Die häufigste Fehlerursache. Stellen Sie sicher, dass der in Ihrer Anwendung konfigurierte URI EXAKT mit dem in der App-Registrierung übereinstimmt (Groß-/Kleinschreibung, Pfade, Schemata).
• Fehlende oder falsche API-Berechtigungen: Die Anwendung kann nicht auf eine Ressource zugreifen, weil die erforderliche Berechtigung fehlt oder nicht korrekt erteilt wurde (z.B. Admin-Einwilligung erforderlich).
• Ungültiger Kontotyp: Ein Benutzer versucht, sich mit einem Kontotyp anzumelden, der von der App-Registrierung nicht unterstützt wird (z.B. ein persönliches Microsoft-Konto bei einer Single-Tenant-Anwendung).
• Abgelaufenes Client-Geheimnis/Zertifikat: Führt zu Authentifizierungsfehlern. Regelmäßige Rotation und Überwachung sind hier wichtig.
• Impliziter Flow für nicht-SPA-Anwendungen: Wenn der implizite Flow für eine Server-Web-App aktiviert ist, kann dies zu Sicherheitsproblemen führen, wenn nicht korrekt implementiert.

Fazit

Die Microsoft Entra ID App-Registrierung ist ein Eckpfeiler moderner, sicherer Anwendungsentwicklung in der Microsoft Cloud. Ihre Plattformkonfiguration ist keine bloße Formalität, sondern ein kritischer Schritt, der die Sicherheit, Funktionalität und das Benutzererlebnis Ihrer Anwendung maßgeblich beeinflusst. Indem Sie die verschiedenen Plattformtypen verstehen, die Best Practices für Umleitungs-URIs und Authentifizierungs-Flows anwenden und stets das Prinzip der geringsten Rechte verfolgen, schaffen Sie eine robuste und sichere Grundlage für Ihre Anwendungen.

Nehmen Sie sich die Zeit, die Konfigurationen sorgfältig durchzugehen und zu verstehen, was jede Option bedeutet. Eine gut konfigurierte App-Registrierung ist der Schlüssel zu einer nahtlosen und sicheren Integration Ihrer Anwendungen in das Microsoft Entra ID-Ökosystem, heute und in der Zukunft.