Gliederung und Einschränkungen für Umleitungs-URI (Antwort-URL)

Artikel
07/03/2024

Um eine Benutzerin oder einen Benutzer anzumelden, muss Ihre App eine Anmeldeanforderung an den Microsoft Entra-Autorisierungsendpunkt senden, wobei ein Umleitungs-URI als Parameter angegeben ist. Der Umleitungs-URI ist ein wichtiges Sicherheitsfeature, das sicherstellt, dass der Microsoft Entra-Authentifizierungsserver Autorisierungscodes und Zugriffstoken nur an den vorgesehenen Empfänger sendet. In diesem Artikel werden die Features und Einschränkungen von Umleitungs-URIs in der Microsoft Identity Platform beschrieben.

Was ist eine Umleitungs-URI?

Ein Umleitungs-URI oder eine Antwort-URL definiert den Ort, an den der Microsoft Entra-Authentifizierungsserver die Benutzerin oder den Benutzer umleitet, sobald sie erfolgreich autorisiert wurden und einen Zugriffstoken erhalten haben. Um eine Benutzerin oder einen Benutzer anzumelden, muss Ihre Anwendung eine Anmeldeanforderung mit einer als Parameter angegebenen Umleitungs-URI senden. Nachdem die Benutzerin oder der Benutzer sich erfolgreich angemeldet hat, leitet der Authentifizierungsserver die Benutzerin oder den Benutzer um und gibt ein Zugriffstoken an die in der Anmeldeanforderung angegebene Umleitungs-URI aus.

Warum müssen Umleitungs-URIs zu einer App-Registrierung hinzugefügt werden?

Aus Sicherheitsgründen leitet der Autorisierungsserver Benutzerinnen und Benutzer nicht um oder sendet Token an einen URI, der der App-Registrierung nicht hinzugefügt wurde. Microsoft Entra-Anmeldeserver leiten Benutzerinnen und Benutzer und senden Token nur an Umleitungs-URIs, die einer App-Registrierung hinzugefügt wurden. Wenn der in der Anmeldeanforderung angegebene Umleitungs-URI keiner der Umleitungs-URIs entspricht, die Sie in Ihrer Anwendung hinzugefügt haben, wird eine Fehlermeldung wie AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application angezeigt.

Weitere Informationen zu Fehlercodes finden Sie unter Microsoft Entra-Authentifizierungs- und Autorisierungsfehlercodes.

Soll ich eine Umleitungs-URI zu einer App-Registrierung hinzufügen?

Ob Sie ihrer App-Registrierung einen Umleitungs-URI hinzufügen sollten, hängt vom Autorisierungsprotokoll ab, das Ihre Anwendung verwendet. Sie müssen Ihrer App-Registrierung entsprechende Umleitungs-URIs hinzufügen, wenn Ihre Anwendung die folgenden Autorisierungsprotokolle verwendet:

Sie müssen Ihrer App-Registrierung keine Umleitungs-URIs hinzufügen, wenn Ihre Anwendung die folgenden Autorisierungsprotokolle oder Funktionen verwendet.

Zu welcher Plattform sollte ich meine Umleitungs-URI(s) hinzufügen?

Wenn die Anwendung, die Sie erstellen, eine oder mehrere Umleitungs-URIs in Ihrer App-Registrierung enthält, müssen Sie eine öffentliche Client Flow-Konfiguration aktivieren. In den folgenden Tabellen finden Sie Anhaltspunkte für die Art des Umleitungs-URI, die Sie je nach der Plattform, auf der Sie Ihre Anwendung erstellen, hinzufügen sollten oder nicht.

Konfiguration des Umleitungs-URI für Webanwendungen

Art Ihrer Anwendung	Typische Sprachen/Frameworks	Plattform zum Hinzufügen von Umleitungs-URI in der App-Registrierung
Eine herkömmliche Webanwendung, bei der der größte Teil der Anwendungslogik auf dem Server ausgeführt wird	Node.js, web, ASP.NET, Python, Java, ASP.NET Core, PHP, Ruby, Blazor Server	Web
Eine Single-Page-Webanwendung, bei der der Großteil der Logik der Benutzeroberfläche in einem Webbrowser ausgeführt wird, der mit dem Webserver hauptsächlich über Web-APIs kommuniziert.	JavaScript, Angular, React, Blazor WebAssembly, Vue.js	Single-Page-Webanwendung (SPA)

Konfiguration des Umleitungs-URI für mobile und Desktopanwendungen

Art Ihrer Anwendung	Typische Sprachen/Frameworks	Plattform zum Hinzufügen von Umleitungs-URI in der App-Registrierung
Eine iOS- oder macOS-App mit Ausnahme der Szenarien, die unter dieser Tabelle aufgeführt sind	Swift, Objective-C, Xamarin	iOS/macOS
Eine Android-App	Java, Kotlin, Xamarin	Android
Eine App, die nativ auf einem mobilen Gerät oder einem Desktopcomputer ausgeführt wird.	Node.js Electron, Windows Desktop, UWP, React Native, Xamarin, Android, iOS/macOS	Mobile Anwendungen und Desktopanwendungen

Wenn Sie eine iOS-App mit einer der folgenden Methoden erstellen, verwenden Sie die Plattform Mobile- und Desktopanwendungen, um die Umleitungs-URI hinzuzufügen:

iOS-Apps mit älteren SDKs (ADAL)
iOS-Apps mit Open Source-SDKs (AppAuth)
iOS-Apps mit plattformübergreifender Technologie, die wir nicht unterstützen (Flutter)
iOS-Apps, die unsere OAuth-Protokolle direkt implementieren
macOS-Apps mit plattformübergreifender Technologie, die wir nicht unterstützen (Electron)

Anwendungen, die keinen Umleitungs-URI erfordern

Art der Anwendung	Beispiele/Hinweise	Zugeordneter OAuth-Flow
Anwendungen, die auf Geräten ohne Tastatur ausgeführt werden	Anwendungen, die auf Smart TV-, IoT-Geräten oder Druckern ausgeführt werden	Gerätecodeflow Weitere Informationen
Anwendungen, die die von den Benutzerinnen und Benutzern eingegebenen Kennwörter direkt verarbeiten, anstatt sie auf die von Entra gehostete Login-Website umzuleiten und Entra die sichere Verwaltung der Kennwörter der Benutzerinnen und Benutzer zu überlassen.	Sie sollten diesen Flow nur verwenden, wenn andere sicherere Flows wie Autorisierungscodefluss nicht geeignet sind, da er nicht so sicher ist.	Anmeldeflow mit Kennwort des Ressourcenbesitzerkontos Weitere Informationen
Desktop- oder mobile Anwendungen, die unter Windows oder auf einem Computer laufen, der mit einer Windows-Domäne (AD oder Azure AD joined) verbunden ist und den integrierten Windows Authentifizierungsflow anstelle des Webkonto-Managers verwendet	Eine Desktop- oder mobile Anwendung, die die Anmeldung automatisch durchführen soll, nachdem sich die Benutzerin oder der Benutzer mit einer Entra-Anmeldedatenbank am Windows-PC-System angemeldet hat	Integrierter Windows-Authentifizierungsflow Weitere Informationen

Welche Einschränkungen gelten für Umleitungs-URIs für Microsoft Entra-Anwendungen?

Das Microsoft Entra-Anwendungsmodul gibt die folgenden Einschränkungen zum Umleiten von URIs an:

Umleitungs-URIs müssen mit dem Schema https beginnen, mit Ausnahme für einige localhost-Umleitungs-URIs.
Bei Umleitungs-URIs wird die Kleinschreibung beachtet, und sie müssen mit der Schreibweise des URL-Pfads Ihrer ausgeführten Anwendung übereinstimmen.

Beispiele:
- Wenn Ihre Anwendung beispielsweise .../abc/response-oidc als Teil des Pfads enthält, geben Sie in des Umleitungs-URI nicht .../ABC/response-oidc an. Weil der Webbrowser bei Pfaden die Groß-/Kleinschreibung beachtet, werden Cookies, die .../abc/response-oidc zugeordnet sind, möglicherweise ausgeschlossen, wenn eine Umleitung an die anders geschriebene (nicht übereinstimmende) URL .../ABC/response-oidc erfolgt.
Umleitungs-URIs, die nicht mit einem Pfadsegment konfiguriert sind, werden in der Antwort mit einem nachgestellten Schrägstrich ('/') zurückgegeben. Dies gilt nur, wenn der Antwortmodus query oder fragment ist.

Beispiele:
- https://contoso.com wird als https://contoso.com/ zurückgegeben.
- http://localhost:7071 wird als http://localhost:7071/ zurückgegeben.
Umleitungs-URIs, die ein Pfadsegment enthalten, werden in der Antwort nicht mit einem nachgestellten Schrägstrich zurückgegeben.

Beispiele:
- https://contoso.com/abc wird als https://contoso.com/abc zurückgegeben.
- https://contoso.com/abc/response-oidc wird als https://contoso.com/abc/response-oidc zurückgegeben.
Umleitungs-URIs unterstützen keine Sonderzeichen: ! $ ' ( ) , ;

Maximale Anzahl von Umleitungs-URIs und URI-Länge

Die maximale Anzahl von Umleitungs-URIs kann aus Sicherheitsgründen nicht ausgelöst werden. Wenn die Anzahl der in Ihrem Szenario erforderlichen Umleitungs-URIs den zulässigen Höchstwert überschreitet, sollten Sie anstelle eines Umleitungs-URIs mit Platzhalter den folgenden Ansatz mit Statusparameter in Betracht ziehen. Die folgende Tabelle zeigt die maximale Anzahl von Umleitungs-URIs, die Sie einer App-Registrierung in Microsoft Identity Plattform hinzufügen können.

Angemeldete Konten	Maximale Anzahl von Umleitungs-URIs	Beschreibung
Geschäfts-, Schul- oder Unikonten von Microsoft in dem Microsoft Entra-Mandanten einer Organisation	256	Das Feld `signInAudience` im Anwendungsmanifest ist entweder auf AzureADMyOrg oder AzureADMultipleOrgs eingestellt
Persönliche Konten sowie Geschäfts-, Schul- und Unikonten von Microsoft	100	Das Feld `signInAudience` im Anwendungsmanifest ist auf AzureADandPersonalMicrosoftAccount eingestellt

Für jeden Umleitungs-URI, den Sie einer App-Registrierung hinzufügen, können Sie maximal 256 Zeichen verwenden.

Umleitungs-URIs in Anwendungsobjekten und Dienstprinzipalobjekten

Fügen Sie Umleitungs-URIs immer nur dem Anwendungsobjekt hinzu.
Einem Dienstprinzipal sollten Sie nie Umleitungs-URI-Werte hinzufügen, da diese Werte entfernt werden können, wenn das Dienstprinzipalobjekt mit dem Anwendungsobjekt synchronisiert wird. Dies kann durch einen Aktualisierungsvorgangs geschehen, der eine Synchronisierung zwischen den beiden Objekten auslöst.

Unterstützung von Abfrageparametern in Umleitungs-URIs

Abfrageparameter sind in Umleitungs-URIs für Anwendungen zulässig, die nur Benutzer mit Geschäfts-, Schul- oder Unikonten anmelden.

Abfrageparameter sind nicht zulässig in Umleitungs-URIs für alle App-Registrierungen, die für die Anmeldung von Benutzerinnen und Benutzern mit persönlichen Microsoft-Konten wie Outlook.com (Hotmail), Messenger, OneDrive, MSN, Xbox Live oder Microsoft 365 konfiguriert sind.

Zielgruppe für die Anmeldung bei App-Registrierung	Unterstützt Abfrageparameter in Umleitungs-URI
Nur Konten in diesem Organisationsverzeichnis (Nur Contoso – einzelner Mandant)
Konten in einem beliebigen Organisationsverzeichnis (beliebiges Microsoft Entra-Verzeichnis – mehrinstanzenfähig)
Konten in einem beliebigen Organisationsverzeichnis (beliebiges Microsoft Entra-Verzeichnis – mehrinstanzenfähig) und persönliche Microsoft-Konten (wie Skype und Xbox)
Nur persönliche Microsoft-Konten

Unterstützte Schemas

HTTPS: Das HTTPS-Schema (https://) wird für alle HTTP-basierten Umleitungs-URIs unterstützt.

HTTP: Das HTTP-Schema (http://) wird nur für localhost-URIs unterstützt und sollte nur während der Entwicklung und Tests der aktiven lokalen Anwendung verwendet werden.

Beispiel für Umleitungs-URI	Gültigkeitsdauer
`https://contoso.com`	Gültig
`https://contoso.com/abc/response-oidc`	Gültig
`https://localhost`	Gültig
`http://contoso.com/abc/response-oidc`	Ungültig
`http://localhost`	Gültig
`http://localhost/abc`	Gültig

Ausnahmen für Localhost

Gemäß RFC 8252, Abschnitte 8.3 und 7.3, gelten für die Umleitungs-URIs „loopback“ und „localhost“ zwei Besonderheiten:

http-URI-Schemas sind akzeptabel, da die Umleitung das Gerät niemals verlässt. Daher sind die beiden folgenden URIs akzeptabel:
- http://localhost/myApp
- https://localhost/myApp
Aufgrund kurzlebiger Portbereiche, die häufig von nativen Anwendungen benötigt werden, wird die Portkomponente (z. B. :5001 oder :443) beim Abgleich eines Umleitungs-URI ignoriert. Folglich werden alle diese URIs als gleichwertig betrachtet:
- http://localhost/MyApp
- http://localhost:1234/MyApp
- http://localhost:5000/MyApp
- http://localhost:8080/MyApp

Aus Entwicklersicht bedeutet dies Folgendes:

Registrieren Sie nicht mehrere Umleitungs-URIs, wenn sich nur der Port unterscheidet. Der Anmeldeserver wählt willkürlich einen Umleitungs-URI aus und verwendet das diesem zugeordnete Verhalten (z. B. entsprechend dem Umleitungstyp web, native oder spa).

Dies ist besonders dann wichtig, wenn Sie in ein und derselben Anwendungsregistrierung verschiedene Authentifizierungsflows verwenden möchten, beispielsweise die Autorisierungscodegenehmigung und den impliziten Flow. Um jedem Umleitungs-URI das richtige Antwortverhalten zuzuordnen, muss der Anmeldeserver zwischen den verschiedenen URIs unterscheiden können. Dies ist nur mit unterschiedlichen Ports möglich.
Wenn Sie mehrere Umleitungs-URIs für den Localhost registrieren, um während der Entwicklung verschiedene Flows zu testen, unterscheiden Sie diese mithilfe der path-Komponente des URI. Beispielsweise stimmt http://localhost/MyWebApp nicht mit http://localhost/MyNativeApp überein.
Die IPv6-Loopback Adresse ([::1]) wird derzeit nicht unterstützt.

127.0.0.1 anstelle von localhost

Um Fehler in Ihrer App aufgrund falsch konfigurierter Firewalls oder umbenannter Netzwerkschnittstellen zu vermeiden, verwenden Sie in Ihrem Umleitungs-URI anstelle von localhost die tatsächliche IP-Loopbackadresse 127.0.0.1. Beispiel: https://127.0.0.1.

Sie können jedoch nicht das Textfeld Umleitungs-URIs im Azure-Portal verwenden, um einen loopbackbasierten Umleitungs-URI mit dem http-Schema hinzuzufügen:

Fehlerdialogfeld im Azure-Portal mit unzulässigem HTTP-basiertem Loopback-Umleitungs-URI

Zum Hinzufügen eines Umleitungs-URI, der das http-Schema verwendet, mit der tatsächlichen Loopbackadresse 127.0.0.1 müssen Sie derzeit das replyUrlsWithType-Attribut im Anwendungsmanifest ändern.

Einschränkungen für Platzhalter in Umleitungs-URIs

Platzhalter in URIs wie https://*.contoso.com sind möglicherweise bequem, sind jedoch aufgrund von Sicherheitsrisiken zu vermeiden. Gemäß der OAuth 2.0-Spezifikation (RFC 6749, Abschnitt 3.1.2) muss ein Umleitungsendpunkt-URI ein absoluter URI sein. Wenn also ein konfigurierter URI mit Platzhalter mit einem Umleitungs-URI übereinstimmt, werden Abfragezeichenfolgen und Fragmente im Umleitungs-URI entfernt.

URIs mit Platzhalter werden derzeit in App-Registrierungen, die für die Anmeldung von persönlichen Microsoft-Konten und von Geschäfts-, Schul- oder Unikonten konfiguriert sind, nicht unterstützt. URIs mit Platzhalter sind jedoch zulässig bei Apps, die nur für die Anmeldung von Geschäfts-, Schul- oder Unikonten bei einem Microsoft Entra -Mandanten in einer Organisation konfiguriert sind.

Verwenden Sie im Azure-Portal unter App-Registrierungen den Anwendungsmanifest-Editor, um Umleitungs-URIs mit Platzhaltern zu App-Registrierungen hinzuzufügen, die Geschäfts-, Schul- oder Unikonten anmelden. Auch wenn Sie mit dem Manifest-Editor einen Umleitungs-URI mit Platzhalter festlegen können, empfehlen wir dringend, den Abschnitt 3.1.2 von RFC 6749 zu beachten und ausschließlich absolute URIs zu verwenden.

Wenn die Anzahl der in Ihrem Szenario erforderlichen Umleitungs-URIs den zulässigen Höchstwert überschreitet, sollten Sie anstelle eines Umleitungs-URIs mit Platzhalter den folgenden Ansatz mit Statusparameter in Betracht ziehen.

Verwenden eines Statusparameters

Wenn Sie mehrere Unterdomänen haben und in Ihrem Szenario Benutzer nach erfolgreicher Authentifizierung wieder auf die Ausgangsseite umgeleitet werden müssen, kann die Verwendung eines Statusparameters hilfreich sein.

Dieser Ansatz ermöglicht Folgendes:

Erstellen eines „gemeinsamen“ Umleitungs-URIs pro Anwendung, um die vom Autorisierungsendpunkt empfangenen Sicherheitstoken zu verarbeiten.
Ihre Anwendung kann anwendungsspezifische Parameter (z. B. URL der Unterdomäne, aus welcher der Benutzer stammt, oder andere Parameter wie Brandinginformationen) im Statusparameter senden. Wenn Sie einen Zustandsparameter verwenden, schützen Sie sich vor CSRF, wie in Abschnitt 10.12 von RFC 6749 beschrieben.
Die anwendungsspezifischen Parameter enthalten alle Informationen, die die Anwendung benötigt, um die richtige Umgebung für den Benutzer zu rendern (d. h., den entsprechenden Anwendungsstatus zu erstellen). Der Microsoft Entra-Autorisierungsendpunkt entfernt HTML aus dem Statusparameter. Stellen Sie also sicher, dass Sie in diesem Parameter keinen HTML-Inhalt übergeben.
Wenn Microsoft Entra ID eine Antwort an den „gemeinsamen“ Umleitungs-URI sendet, wird gleichzeitig der Statusparameter an die Anwendung zurückgesendet.
Die Anwendung kann dann anhand des Werts im Statusparameter bestimmen, an welche URL der Benutzer weitergeleitet werden soll. Stellen Sie eine Überprüfung in Bezug auf CSRF-Schutz sicher.

Warnung

Dieser Ansatz ermöglicht einem kompromittierten Client, die im Statusparameter gesendeten zusätzlichen Parameter zu ändern, wodurch der Benutzer zu einer anderen URL umgeleitet wird. Dieser Open Redirect-Angriff (Sicherheitsrisiko durch offene Umleitung) ist in RFC 6819 beschrieben. Daher muss der Client diese Parameter schützen, indem er den Status verschlüsselt oder auf andere Weise verifiziert, z. B. durch Überprüfen des Domänennamens im Umleitungs-URI anhand des Tokens.

Nächste Schritte

Erfahren Sie mehr über das Anwendungsmanifest der App-Registrierung.

Teilen über