Freigeben über

Authentifizieren von Anwendungen und Benutzern mit Microsoft Entra ID

  • Artikel

Eine primäre Microsoft Entra ID-Funktion für Apps ist die Authentifizierung, der Prozess, in dem Benutzer ihre Identität mit einem persönlichen Bezeichner deklarieren, z. B. mit einem Benutzernamen oder einer E-Mail-Adresse. Der Nachweis der Identität wird bereitgestellt. Der Nachweis könnte ein Kennwort, ein Artefakt der Multi-Faktor-Authentifizierung, eine biometrische oder kennwortlose Einwilligung sein.

Dieser Artikel beschreibt, wie Anwendungen Microsoft Entra ID zum Authentifizieren von Benutzern und Anwendungen verwenden. Dies ist der dritte Artikel in einer Reihe zum Thema, wie unabhängige Softwareentwickler (Independent Software Developers, ISVs) ihre Anwendungen für Microsoft Entra ID erstellen und optimieren können. In dieser Reihe können Sie mehr über diese Themen erfahren:

  • Microsoft Entra ID für unabhängige Softwareentwickler beschreibt, wie Sie diesen cloudbasierten Identitäts- und Zugriffsverwaltungsdienst verwenden, um Mitarbeitern mit Ihrer Anwendung den Zugriff auf Ressourcen zu ermöglichen.
  • Einrichten von Anwendungen im Microsoft Entra ID-Ökosystem beschreibt, wie Sie das Microsoft Entra Admin Center oder die Microsoft Graph-API (Application Programming Interface, Anwendungsprogrammierschnittstelle) zum Registrieren von Apps in einem Microsoft Entra ID-Mandanten verwenden.
  • Autorisieren von Anwendungen, Ressourcen und Workloads erläutert die Autorisierung, wenn ein einzelner Mensch mit einer Anwendung interagiert und sie steuert, wenn APIs für einen Benutzer handeln. Zusätzlich werden Szenarien erläutert, in denen Anwendungen oder Dienste unabhängig arbeiten.
  • Anpassen von Token beschreibt, wie Sie ID-Token und Zugriffstoken von Microsoft Entra ID verwenden, um Sicherheit in Anwendungen zu integrieren. Sie erfahren, welche Informationen Sie in Microsoft Entra ID-Token empfangen und wie Sie diese anpassen können.

Anfordern von Token

Anwendungen fordern ein Token von Microsoft Entra ID an. Nachdem Apps das Token empfangen, können sie die Informationen in diesem Token verwenden, um den Benutzer zu identifizieren. Wenn Sie auf Microsoft Entra ID aufbauen, können Benutzer viele Anwendungen mit einem einzigen registrierten Microsoft Entra ID-Konto (SSO) authentifizieren. Die SSO-Authentifizierungsmethode ermöglicht Benutzern die Anmeldung bei mehreren unabhängigen Softwaresystemen mithilfe eines einzigen Satzes von Anmeldeinformationen.

Protokolle, die Entwickler verwenden können, um ein Token von Microsoft Entra ID anzufordern, verwenden einen Browser, um den Benutzer mit der Microsoft Entra ID-Website zu verbinden. Diese Website ermöglicht es dem Benutzer, eine private Unterhaltung mit Microsoft Entra ID zu führen. Eine Anwendung ist kein Teilnehmer in dieser privaten Unterhaltung. Apps starten die Microsoft Entra ID-Website, auf welcher der Benutzer den Authentifizierungsprozess initiiert. Nach Abschluss des Authentifizierungsprozesses leitet Microsoft Entra ID den Benutzer an die Anwendung zurück, mit oder ohne Token.

Es ist wichtig, dass Benutzer den Authentifizierungsprozess nur selten durchlaufen müssen. Je häufiger Benutzer dies tun müssen, desto mehr sind sie anfällig für Exploits wie Phishingangriffe.

Reduzieren von Anmeldeaufforderungen

SSO kann Anmeldeaufforderungen reduzieren oder beseitigen. Entwickler spielen eine wichtige Rolle bei der Verringerung und Beseitigung von Anmeldeaufforderungen. Alle Apps müssen den Browser teilen, der auf die Microsoft Entra ID-Website zugreift, auf welcher die Benutzer den Authentifizierungsprozess ausführen. Wenn Ihre App eine browserbasierte Einzelseitenanwendung (Single Page Application, SPA) oder Web-App ist, sind keine Entwicklerschritte erforderlich. Alle Apps im Browser teilen den Browser. Für native Anwendungen, die auf Desktops und mobilen Geräten ausgeführt werden, müssen Entwickler Anmeldeaufforderungen proaktiv reduzieren oder beseitigen.

Die beste Methode zum Reduzieren oder Beseitigen von Anmeldeaufforderungen ist die Verwendung von Microsoft-Authentifizierungsbibliotheken (Microsoft Authentication Libraries, MSALs) oder einer Bibliothek, die auf MSAL basiert, und Brokerauthentifizierungen. Diese Methode minimiert Anmeldeaufforderungen und bietet die nahtloseste Erfahrung. Wenn die Erstellung auf MSAL nicht möglich ist, sollte Ihre Anwendung den Systembrowser verwenden, um Anmeldeaufforderungen zu minimieren.

Für Apps, die in iOS oder Android ausgeführt werden, verfügen Anbieter mobiler Plattformen über einige Funktionalitäten, um diese Erfahrung nahtloser zu gestalten. Google bietet Anleitungen für Android-Anwendungen mit benutzerdefinierten Chrome-Registerkarten. Apple bietet Anleitungen für die Authentifizierung eines Benutzers über einen Webdienst in iOS-Anwendungen. Vermeiden Sie die Verwendung eingebetteter WebViews, da diese die Freigabe über Apps oder den Systembrowser hinweg möglicherweise nicht zulassen.

Die beiden Protokolle für die Benutzerauthentifizierung sind Security Assertion Markup Language 2.0 (SAML) und OpenID Connect (OIDC). Microsoft Entra ID unterstützt Apps mit beiden Protokollen vollständig, sodass Entwickler je nach ihren Anforderungen eines der beiden Protokolle auswählen können.

Diese Verweise detaillieren die SAML-Unterstützung in Microsoft Entra ID.

Es gibt einige Einschränkungen beim SAML-Support in Microsoft Entra ID. Insbesondere können Sie keine Apps migrieren, welche diese Protokollfunktionalitäten erfordern: Unterstützung für das WS-Trust ActAs-Muster und die SAML-Artefaktauflösung.

Obwohl Microsoft Entra ID SAML für Apps, die auf dem SAML-Protokoll basieren, vollständig unterstützt, stellt die Microsoft-Identitätsplattform keine Bibliotheken oder andere Entwicklungstools für die Entwicklung von Anwendungen mit SAML bereit. Für neue Anwendungsentwicklungen empfehlen wir die Verwendung von OpenID Connect (OIDC) für die Authentifizierung.

Microsoft Entra ID unterstützt OpenID Connect vollständig. Microsoft stellt MSAL-, Microsoft Identity Web- und Azure SDK-Bibliotheken bereit, um die Entwicklung von OIDC-Anwendungen zu vereinfachen. OpenID Connect (OIDC) auf der Microsoft-Identitätsplattform enthält Details zum OIDC-Support in Microsoft Entra ID. MSAL unterstützt OIDC automatisch. MSAL fordert immer ein OIDC-ID-Token mit jeder Tokenanforderung an, einschließlich Autorisierungsanforderungen für eine App für den Zugriff auf eine Ressource.

Lebensdauer von Token

MSAL speichert ID-Token und Zugriffstoken im Cache, basierend auf der Ablaufzeit des Zugriffstokens. Da Microsoft Entra ID die Lebensdauer für ID-Token und Zugriffstoken anders festlegt, erhalten Sie möglicherweise ein abgelaufenes ID-Token aus einem abgelaufenen MSAL-Cache, während das Zugriffstoken noch innerhalb der gültigen Lebensdauer liegt.

MSAL erneuert ID-Token nicht automatisch. MSAL erneuert Zugriffstoken beim Erreichen oder kurz vor Ablauf des Lebenszyklus des Zugriffstokens, wenn eine Anwendung das Token anfordert. Zu diesem Zeitpunkt fordert MSAL ein neues ID-Token an. Um OIDC zu implementieren, verwenden Sie den exp-Anspruch (ablaufen) im ID-Token, um eine ID-Tokenanforderung mithilfe des ForceRefresh-Flags in MSAL zu planen.

Beim Erstellen mit MSAL oder mit einer auf MSAL basierenden Bibliothek ist es nicht möglich, den OpenID Connect-Standard zum Authentifizieren des aktuellen Benutzers zu verwenden. Einige Funktionalitäten in nativen Anwendungen sind möglicherweise ohne die Verwendung von MSAL nicht verfügbar, z. B. das Sicherstellen, dass die native App auf einem verwalteten Gerät ausgeführt wird. Überprüfen Sie Erhöhen der Resilienz der Authentifizierung und Autorisierung in Clientanwendungen, die Sie entwickeln, um Anleitungen zu erhalten, wenn Sie nicht auf MSAL aufbauen.

Microsoft Entra ID implementiert einen UserInfo-Endpunkt als Teil des Supports der OIDC-Standards in Microsoft Entra ID mit einem bestimmten Microsoft Graph-Pfad (https://graph.microsoft.com/oidc/userinfo). Es ist nicht möglich, die vom UserInfo-Endpunkt zurückgegebenen Informationen hinzuzufügen oder anzupassen. Da die Informationen im ID-Token eine Obermenge der Informationen sind, die durch Aufrufen des UserInfo-Endpunkts zurückgegeben werden, empfehlen wir die Verwendung des ID-Tokens anstelle des Aufrufens des UserInfo-Endpunkts.

Benutzer authentifizieren

Anwendungen interagieren mit Microsoft Entra ID-Mandanten, um Benutzer zu authentifizieren. Um einen Benutzer zu authentifizieren, leitet eine Anwendung einen Browser zu https://login.microsoftonline.com/{tenant}/v2.0, wobei {tenant} die ID oder Domäne des Mandanten ist. Es wird jedoch empfohlen, dass ISVs Microsoft Entra ID verwenden, um mandantenfähige Anwendungen zu erstellen, die eine möglichst große Anzahl von Kunden unterstützen. Bei einer mandantenfähigen Anwendung weiß eine App möglicherweise nicht, von welchem Mandanten ein Benutzer stammt, bis sich der Benutzer authentifiziert hat, sodass es nicht möglich ist, einen bestimmten Mandantenendpunkt zu verwenden.

Um mandantenfähige Apps zu aktivieren, stellt Microsoft Entra ID zwei mandantenunabhängige OIDC/OAuth 2.0-Endpunkte bereit:

  • https://login.microsoftonline.com/common/v2.0 ermöglicht Benutzern die Authentifizierung einer App, wenn sie von einem beliebigen Microsoft Entra ID-Mandanten stammen oder über ein Microsoft-Verbraucherkonto von Websites wie outlook.com, skype.com, xbox.com, live.com oder Hotmail.com verfügen.
  • https://login.microsoftonline.com/organizations/v2.0 ermöglicht Benutzern die Authentifizierung einer App, wenn sie von einem beliebigen Microsoft Entra ID-Mandanten stammen.

Diese Endpunkte ermöglichen es jedem Benutzer eines Microsoft Entra ID-Mandanten, Ihre Anwendung zu authentifizieren. Wenn Sie nur Benutzern von bestimmten Mandanten zulassen möchten, implementieren Sie die Logik, um nur Benutzern von diesen Mandanten den Zugriff auf Ihre App zu ermöglichen. Die normale Implementierung besteht darin, Benutzer basierend auf dem iss-Anspruch (Aussteller) oder dem tid-Anspruch (Mandanten-ID) im Token auf eine von Ihnen verwaltete Positivliste von Mandanten zu filtern.

Microsoft Entra ID-Mandanten unterstützen Benutzer, die reguläre Mitglieder oder Gastbenutzer des Mandanten sein können. Standardmäßig gibt es eingeschränkte Funktionalitäten für Gastbenutzer in einem Mandanten. Gastbenutzer können beispielsweise das vollständige Profil anderer Benutzer im Mandanten nicht sehen. Gastbenutzer, manchmal als Business-to-Business (B2B)-Benutzer bezeichnet, ermöglichen verschiedenen Organisationen die Zusammenarbeit mit Tools und Diensten, die von Microsoft Entra ID geschützt werden. Ein Beispielszenario ist das Einladen eines Benutzers von außerhalb Ihrer Organisation, um auf eine SharePoint-Datei in Ihrem Mandanten zuzugreifen. In der Regel verwendet ein B2B-Benutzer seine E-Mail-Adresse als seine userid. Er kann jedoch dieselbe Adresse wie die userid in seinem Heimmandanten verwenden. Microsoft Entra ID meldet den Benutzer standardmäßig bei seinem Heimmandanten an, wenn er seine userid eingibt.

Um einen Benutzer als B2B-Benutzer anzumelden, muss eine Anwendung den bestimmten Mandantenendpunkt verwenden, in dem der Benutzer ein Gast ist. Es ist zwar möglich, dass ein Benutzer einen Mandanten angibt, auf den er zugreifen möchte, wenn eine Anwendung den https://login.microsoftonline.com/organizations/v2.0-Endpunkt verwendet, aber für die Benutzer ist diese Funktionalität möglicherweise schwer zu entdecken.

Nächste Schritte