Desktop-App, die Web-APIs aufruft: App-Registrierung

  • Artikel

In diesem Artikel sind die Besonderheiten zur App-Registrierung bei einer Desktopanwendung aufgeführt.

Unterstützte Kontotypen

Die in einer Desktopanwendung unterstützten Kontotypen sind von der gewünschten Funktion abhängig. Aufgrund dieser Beziehung sind die unterstützten Kontotypen von den Flows abhängig, die Sie verwenden möchten.

Zielgruppe für den interaktiven Tokenabruf

Wenn Ihre Desktopanwendung die interaktive Authentifizierung verwendet, können Sie Benutzer jedes Kontotyps anmelden.

Zielgruppe für automatische Desktop-App-Flüsse

  • Ihre Anwendung muss Benutzer bei Ihrem Mandanten anmelden, um die integrierte Windows-Authentifizierung oder Benutzername und Kennwort verwenden zu können, beispielsweise wenn Sie LOB-Entwickler (Line of Business) sind. In Microsoft Entra-Organisationen muss Ihre Anwendung Benutzer bei Ihrem Mandanten anmelden, wenn es sich um ein ISV-Szenario handelt. Diese Authentifizierungsflows werden für persönliche Microsoft-Konten nicht unterstützt.
  • Wenn Sie Benutzer mit Identitäten sozialer Netzwerke anmelden, die eine B2C-Autorität und -Richtlinie übergeben, können Sie ausschließlich die interaktive Authentifizierung oder die Authentifizierung über Benutzername und Kennwort verwenden.

Umleitungs-URIs

Die in einer Desktopanwendung zu verwendenden Umleitungs-URIs hängen von dem Flow ab, den Sie verwenden möchten.

Geben Sie den Umleitungs-URI für Ihre App an, indem Sie im Microsoft Entra Admin Center unter App-Registrierungen die Plattformeinstellungen konfigurieren.

  • Für Apps, die Webauthentifizierungs-Manager (WAM)verwenden, müssen Umleitungs-URIs nicht in MSAL, sondern in der App-Registrierung konfiguriert werden.

  • Für Apps mit interaktiver Authentifizierung:

    • Apps, die eingebettete Browser verwenden: https://login.microsoftonline.com/common/oauth2/nativeclient (Hinweis: Wenn Ihre App ein Fenster öffnet, das in der Regel keine Adressleiste enthält, wird der „eingebettete Browser“ verwendet.)
    • Apps, die Systembrowser verwenden: http://localhost (Hinweis: Wenn Ihre App den Standardbrowser Ihres Systems (z. B. Edge, Chrome, Firefox usw.) zum Besuchen des Microsoft-Anmeldeportals verwenden würde, wird der „Systembrowser“ verwendet.)

    Wichtig

    Als bewährte Sicherheitsmaßnahme wird empfohlen, als Umleitungs-URI https://login.microsoftonline.com/common/oauth2/nativeclient oder http://localhost festzulegen. Manche Authentifizierungsbibliotheken wie MSAL.NET verwenden als Standardeinstellung urn:ietf:wg:oauth:2.0:oob (nicht empfohlen), wenn kein anderer Umleitungs-URI angegeben wird. Diese Standardeinstellung wird als Breaking Change in der nächsten Hauptversion aktualisiert.

  • Wenn Sie eine native Objective-C-oder Swift-App für macOS erstellen, sollten Sie den Umleitungs-URI basierend auf der Paket-ID Ihrer Anwendung im folgenden Format registrieren: msauth.<your.app.bundle.id>://auth. Ersetzen Sie <your.app.bundle.id> durch die Paket-ID Ihrer Anwendung.

  • Wenn Sie eine Node.js Electron-App erstellen möchten, verwenden Sie anstelle eines regulären Web-Umleitungs-URIs (https://) ein benutzerdefiniertes Zeichenfolgenprotokoll, um den Umleitungsschritt im Autorisierungsflow zu verarbeiten, z. B. msal{Your_Application/Client_Id}://auth (Beispiel: msalfa29b4c9-7675-4b61-8a0a-bf7b2b4fda91://auth). Der Name des benutzerdefinierten Zeichenfolgenprotokolls sollte nicht offensichtlich und somit leicht zu erraten sein. Befolgen Sie hierfür die Vorschläge in der OAuth 2.0-Spezifikation für native Apps.

  • Wenn Ihre App nur die integrierte Windows-Authentifizierung oder Benutzername und Kennwort verwendet, müssen Sie für Ihre Anwendung keinen Umleitungs-URI registrieren. Diese Flows führen einen Roundtrip zum Microsoft Identity Platform v 2.0-Endpunkt aus. Ihre Anwendung wird nicht über einen bestimmten URI zurückgerufen.

  • Konfigurieren Sie Ihre Anwendung als öffentliche Clientanwendung, um Gerätecodeflow, Integrierte Windows-Authentifizierung sowie Benutzername und Kennwort von einer vertraulichen Clientanwendung mit einem Clientanmeldeinformationsflow zu unterscheiden, der in Daemonanwendungen verwendet wird, die alle keinen Umleitungs-URI benötigen. Gehen Sie für diese Konfiguration wie folgt vor:

    1. Während Sie im Microsoft Entra Admin Center sind, wählen Sie Ihre App unter App-Registrierungen aus, und wählen Sie dann Authentifizierung aus.

    2. Wählen Sie unter Erweiterte Einstellungen>Öffentliche Clientflows zulassen>Folgende Flows für Mobilgerät und Desktop aktivieren: die Option Ja aus.

      Enable public client setting on Authentication pane in Azure portal

API-Berechtigungen

Desktopanwendungen rufen APIs für den angemeldeten Benutzer auf. Sie müssen delegierte Berechtigungen anfordern. Sie können keine Anwendungsberechtigungen anfordern, die nur in Daemon-Anwendungen verarbeitet werden.

Nächste Schritte

Fahren Sie mit dem nächsten Artikel in diesem Szenario fort: App-Codekonfiguration.