Authentifizieren von Benutzern für Zero Trust

Dieser Artikel hilft Ihnen als Entwickler, bewährte Methoden für die Authentifizierung Ihrer Anwendungsbenutzer in der Zero Trust-Anwendungsentwicklung zu erlernen. Verbessern Sie Ihre Anwendungssicherheit immer mit den Zero Trust-Prinzipien der geringsten Berechtigung und überprüfen Sie dies explizit.

ID-Token in der Benutzerauthentifizierung

Wenn Sie einen Benutzer bei Ihrer App authentifizieren müssen, anstatt einen Benutzernamen und ein Kennwort zu generieren, kann Ihre Anwendung ein Identitätstoken (ID) anfordern. Durch die Authentifizierung von Benutzern über die Microsoft Identity Platform werden Sicherheitsrisiken vermieden, die auftreten, wenn Ihre Anwendung Benutzeranmeldeinformationen beibehält. Wenn Sie ID-Token anfordern, wenn ein Hacker Ihre Anwendung verletzt oder kompromittiert, gibt es keine Benutzernamen und entsprechenden Kennwörter, geheimen Schlüssel und Zertifikate in Ihrer App.

Das Microsoft Identity Platform ID-Token ist Teil des OpenID Connect (OIDC)-Standards, der ID-Token als JSON-Webtoken (JWT) angibt. Die lange JWT-Zeichenfolge besteht aus drei Komponenten:

1. Headeransprüche. Die in ID-Token vorhandenen Headeransprüche umfassen typ (Typanspruch), alg (Algorithmus zum Signieren des Tokens) und kid (Fingerabdruck für den öffentlichen Schlüssel, um die Signatur des Tokens zu überprüfen).
2. Nutzlastansprüche. Die Nutzlast oder der Textkörper (der mittlere Teil eines JSON-Webtokens) enthält eine Reihe von Namensattributpaaren. Der Standard erfordert, dass ein Anspruch mit dem iss (Ausstellernamen) vorhanden ist, der an die Anwendung geht, die den Anspruch ausgestellt hat (der Anspruch oder der audZielgruppenanspruch).
3. Signatur: Microsoft Entra ID generiert die Tokensignatur, die Apps verwenden können, um zu überprüfen, ob das Token unverändert ist, und Sie können dem vertrauen.

Im folgenden Beispiel eines ID-Tokens werden Informationen zum Benutzer angezeigt und die Authentifizierung zur Verwendung der Anwendung bestätigt.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "6cb04018-a3f5-46a7-b995-940c78f5aef3",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "00000000-0000-0000-66f3-3332eca7ea81",
  "tid": "3338040d-6c67-4c5b-b112-36a304b66dad",
}.
.[Signature]

ID-Token in der Zugriffsverwaltung

Um Ihre Anwendungs-ID (Client-ID) zu erhalten, registrieren Sie Ihre App bei der Microsoft Identity Platform. Wenn Sie ein Token mit einem Zielgruppenanspruch (aud) erhalten, der der Client-ID Ihrer App entspricht, hat sich der identifizierte Benutzer im Token bei Ihrer App authentifiziert. IT-Administratoren können es allen Benutzern im Mandanten ermöglichen, Ihre App zu verwenden. Sie können zulassen, dass eine Gruppe, von der der Benutzer Mitglied ist, Ihre App verwenden kann.

Wenn Sie ein Token erhalten, dessen Zielgruppenanspruch sich von der Client-ID Ihrer App unterscheidet, lehnen Sie das Token sofort ab. Der Benutzer hat sich nicht authentifiziert, indem er sich bei Ihrer App angemeldet hat. Sie haben sich bei einer anderen App angemeldet. Stellen Sie immer sicher, dass der Benutzer über die Berechtigung zum Verwenden Ihrer App verfügt.

Diese Anspruchsdetails sind bei der Benutzerauthentifizierung wichtig:

• Ein JSON-Webtoken ist gültig, bis es abläuft. Der exp Anspruch (Ablauf) teilt Ihnen mit, wann das Token abläuft. Wenn die aktuelle Uhrzeit vor dem Zeitpunkt im exp Anspruch liegt, ist das Token gültig.
• Betrachten Sie den Benutzer nicht als authentifiziert, bevor die im nbf Anspruch angegebene Zeit (nicht vor dem Zeitpunkt) angegeben ist. Die Uhrzeiten nbf und exp des Tokens definieren die gültige Lebensdauer des Tokens. Wenn die Ablaufzeit bevorsteht, stellen Sie sicher, dass Sie ein neues ID-Token erhalten.
• sub (Antragstelleranspruch) ist ein eindeutiger Bezeichner für einen Anwendungsbenutzer. Derselbe Benutzer hat einen anderen sub Anspruch für andere Apps. Wenn Sie Daten speichern möchten, die einem Benutzer zugeordnet werden sollen und verhindern möchten, dass ein Angreifer diese Zuordnung vornimmt, verwenden Sie den Antragstelleranspruch. Da die Microsoft Entra-Identität des Benutzers nicht verfügbar gemacht wird, ist es die sicherste Methode, Daten einem Benutzer zuzuordnen. Der sub Anspruch ist unveränderlich.
• Wenn Sie Informationen über mehrere Anwendungen hinweg freigeben möchten, verwenden Sie die Kombination aus Mandanten-ID- (tid) und Objekt-ID (oid)-Ansprüchen, die für den Benutzer eindeutig sind. Die kombinierte Mandanten- und Objekt-ID sind unveränderlich.
• Unabhängig davon, was mit der Identität einer Person passiert, sub, oidund tid-Ansprüche bleiben unveränderlich. Alles über den Benutzer kann sich ändern, und Sie können Ihre Daten trotzdem dafür entschlüsseln, den Benutzer basierend auf dem Betreff oder den kombinierten tid und oid-Ansprüchen zu identifizieren.

Authentifizierung mit OIDC

Um die Benutzerauthentifizierung zu veranschaulichen, sehen wir uns Anwendungen an, die OIDC zum Authentifizieren eines Benutzers verwenden. Die gleichen Prinzipien gelten für Apps, die SAML oder WS-Federation verwenden.

Eine App authentifiziert den Benutzer, wenn die Anwendung ein ID-Token von der Microsoft Identity Platform anfordert. Workloads (Anwendungen, die keine Benutzer haben, sondern als Dienste, Hintergrundprozesse, Daemons ausgeführt werden) überspringen diesen Schritt.

Sie sollten dieses Token immer im Hintergrund anfordern. Zum automatischen Abrufen eines Tokens in Microsoft Authentication Libraries (MSAL) kann Ihre App mit der AcquireTokenSilent-Methode beginnen. Wenn Ihre App sich authentifizieren kann, ohne den Benutzer zu stören, empfängt sie das angeforderte ID-Token.

Wenn die Microsoft Identity Platform die Anforderung nicht abschließen kann, ohne mit dem Benutzer zu interagieren, muss Ihre App auf die MSAL-Methode AcquireTokenInteractive zurückgreifen. Um ein Token interaktiv zu erwerben, führen Sie die Anforderung aus, indem Sie eine Weboberfläche mit einer Adresse unter der https://login.microsoftonline.com-Domäne öffnen.

Auf dieser Weboberfläche hat der Benutzer eine private Konversation mit der Microsoft Identity Platform. Ihre App hat keine Einsicht in diese Unterhaltung und keine Kontrolle darüber. Die Microsoft Identity Platform kann eine Benutzer-ID und ein Kennwort, eine mehrstufige Authentifizierung (MFA), eine kennwortlose Authentifizierung oder eine andere Authentifizierungsinteraktion anfordern, die der IT-Administrator oder Benutzer konfiguriert hat.

Ihre Anwendung erhält ein ID-Token, nachdem der Benutzer die erforderlichen Authentifizierungsschritte ausgeführt hat. Wenn Ihre App das Token empfängt, können Sie sicher sein, dass die Microsoft Identity Platform den Benutzer authentifiziert hat. Wenn Ihre App kein ID-Token empfängt, hat die Microsoft Identity Platform den Benutzer nicht authentifiziert. Lassen Sie nicht zu, dass nicht authentifizierte Benutzer in gesicherten Bereichen Ihrer App fortfahren.

Es wird empfohlen, dass Anwendungen eine Sitzung für einen Benutzer erstellen, nachdem sie ein ID-Token von Microsoft Entra ID erhalten hat. Im ID-Token, das eine App empfängt, einen Ablaufanspruch (exp) mit einem Unix-Zeitstempel. Dieser Zeitstempel gibt die Ablaufzeit am oder nach an, in der die App das JWT nicht zur Verarbeitung akzeptieren darf. Verwenden Sie diese Tokenablaufzeit, um die Lebensdauer Ihrer Benutzersitzungen zu steuern. Der exp Anspruch spielt eine entscheidende Rolle bei der Beibehaltung eines explizit überprüften Benutzers vor der App mit den richtigen Berechtigungen und für den richtigen Zeitraum.

Unterstützung für einmaliges Anmelden

Einmaliges Anmelden (SSO) ist eine Authentifizierungsmethode, mit der sich Benutzer mit einem Satz von Anmeldeinformationen bei mehreren unabhängigen Softwaresystemen anmelden können. SSO ermöglicht es Anwendungsentwicklern, sich nicht bei jeder Anwendung separat und wiederholt anmelden zu müssen. Mit SSO stellen Entwickler sicher, dass alle Anwendungen auf dem Gerät des Benutzers die Weboberfläche freigeben, die den Benutzer authentifiziert. Artefakte auf der Weboberfläche (z. B. Sitzungszustand und Cookies), nach erfolgreichem SSO des Authentifizierungslaufwerks.

Wie im folgenden Diagramm dargestellt, ist der einfachste Anwendungsfall einer freigegebenen Weboberfläche eine App, die in einem Webbrowser ausgeführt wird (z. B. Microsoft Edge, Google Chrome, Firefox, Safari). Browserregisterkarten geben den SSO-Status frei.

Diagrammtitel: Webbrowser – einfachster Fall. In der oberen Mitte des Diagramms ist eine Cloud-Form, die ein Microsoft Entra ID-Symbol enthält. Unterhalb der Cloud-Form ist ein Feld. Eine Linie mit einem Pfeil verbindet die Cloud-Form und das Feld. Die Beschriftung lautet „Angemeldet bleiben, SSO-Statuscookies über Aufrufe hinweg speichern”. Innerhalb des Felds, auf der linken Seite, ist ein Symbol, das wie ein Cookie aussieht. Unterhalb des Cookies ist der Untertitel „Private Unterhaltung mit dem Benutzer”. Unterhalb des Untertitels befindet sich ein Symbol, das den Benutzer darstellt. Links neben diesen drei Komponenten befindet sich innerhalb des Felds ein weiteres Feld. Die Feldbezeichnung lautet „Tabs”. Unterhalb der Beschriftung befinden sich vier quadratische Felder, die Browserfenster in Registerkarten darstellen.

Die Microsoft Identity Platform verwaltet den SSO-Status in einem bestimmten Browser, es sei denn, der Benutzer hat unterschiedliche Browser auf demselben Gerät geöffnet. Unter Windows 10 und höher unterstützt die Microsoft Identity Platform systemeigene Browser-SSO in Internet Explorer und Microsoft Edge. Wenn sich der Benutzer bei Windows angemeldet hat, ermöglichen Arbeitsplatzhilfsmittel in Google Chrome (über die Erweiterung für Windows 10-Konten) und Mozilla Firefox v91+ (über eine Browsereinstellung) jedem Browser das Teilen des SSO-Status.

Wie im folgenden Diagramm dargestellt, ist der Anwendungsfall komplizierter.

Diagrammtitel: Native Anwendungen – eingebettete Browser – kein SSO. In der oberen Mitte des Diagramms ist eine Cloud-Form, die ein Microsoft Entra ID-Symbol enthält. Am unteren Rand des Diagramms sind vier Felder horizontal angeordnet. In der unteren rechten Ecke jedes Felds befindet sich ein Symbol, das einen Benutzer darstellt. Bei jedem der Felder handelt es sich um eine Darstellung von Browserfenstern, einschließlich eines Cookiesymbols und eines Globussymbols. Eine Linie mit einem Pfeil an jedem Ende verbindet die vier Felder mit der Cloud-Form.

Auth-Broker-Ansatz

Ein gängiges Muster besteht darin, dass jede systemeigene App über ein eigenes eingebettetes WebView verfügt, das verhindert, dass sie an SSO teilnimmt. Um dieses Szenario zu beheben, verwendet Microsoft Entra ID einen Authentifizierungsbroker-Ansatz (Auth.-Broker ) für systemeigene Anwendungen, wie im folgenden Diagramm dargestellt.

Diagrammtitel: Auth-Broker-Ansatz. In der oberen Mitte des Diagramms ist eine Cloud-Form, die ein Microsoft Entra ID-Symbol enthält. Unterhalb der Cloud-Form befindet sich ein Rechteck mit der Beschriftung Auth-Broker. Das Rechteck enthält ein Cookiesymbol und ein Globussymbol. Eine Linie mit einem Pfeil verbindet die Cloud-Form und das Rechteck. Am unteren Rand des Diagramms sind vier Felder horizontal angeordnet. In der unteren rechten Ecke jedes Felds befindet sich ein Symbol, das einen Benutzer darstellt. Symbole in jedem Feld stellen Browserfenster dar. Eine Linie mit einem Pfeil an jedem Ende verbindet die vier Felder mit dem Rechteck.

Mit einem Authentifizierungsbroker senden Anwendungen Authentifizierungsanforderungen an den Broker statt direkt an die Microsoft Identity Platform. Auf diese Weise wird der Broker zur freigegebenen Oberfläche für alle Authentifizierungen auf dem Gerät.

Zusätzlich zur Bereitstellung einer freigegebenen Oberfläche bietet der Authentifizierungsbroker weitere Vorteile. Bei der Einführung von Zero Trust möchten Unternehmen möglicherweise nur Anwendungen von unternehmensverwalteten Geräten ausführen. Beispiele für die Unternehmensgeräteverwaltung sind vollständige mobile Geräteverwaltung (MDM) und Szenarien, in denen Benutzer ihre eigenen Geräte mitbringen, die an der Verwaltung mobiler Anwendungen (Mobile Application Management, MAM) teilnehmen.

Standardmäßig isolieren zugrunde liegende Betriebssysteme (Os) Browser. Entwickler benötigen eine engere Verbindung mit dem Betriebssystem, um Vollzugriff auf Gerätedetails zu haben. In Windows ist der Authentifizierungsbroker der Windows Web Account Manager (WAM). Auf anderen Geräten ist der Authentifizierungsbroker entweder die Microsoft Authenticator-App (für Geräte mit iOS oder Android) oder die Unternehmensportal-App (für Geräte mit Android). Anwendungen greifen mit MSAL auf den Authentifizierungsbroker zu. In Windows kann eine App ohne MSAL auf das WAM zugreifen. MSAL ist jedoch die einfachste Möglichkeit für Apps, auf den Authentifizierungsbroker zuzugreifen (insbesondere Apps, die nicht Universal Windows Platform-Apps sind).

Authentifizierungsbroker funktionieren in Kombination mit Microsoft Entra ID, um primäre Aktualisierungstoken (PRIMARY Refresh Tokens, PRT) zu verwenden, die die Notwendigkeit reduzieren, dass Benutzer sich mehrmals authentifizieren müssen. PRTs können bestimmen, ob sich der Benutzer auf einem verwalteten Gerät befindet. Microsoft Entra ID erfordert Authentifizierungsbroker, da so Proof of Possession-Token eingeführt werden, eine sicherere Option gegenüber den heute verbreiteten Bearertoken.

Nächste Schritte

• Problembehandlung bei Microsoft Entra-Zugriffstoken: Überprüfen eines Zugriffstokens beschreibt, wie Sie bei einem Microsoft Entra-Zugriffstoken überprüfen, ob bestimmte Felder mit dem Datensatz übereinstimmen.
• Die Resilienz von Authentifizierungs- und Autorisierungsanwendungen, die Sie entwickeln, befasst sich mit Apps, die die Microsoft Identity Platform und Microsoft Entra ID verwenden. Sie beinhalten Anleitungen für Client- und Service-Anwendungen, die im Auftrag eines angemeldeten Benutzers arbeiten, sowie für Daemon-Anwendungen, die im eigenen Auftrag arbeiten. Sie enthalten bewährte Methoden für die Verwendung von Token und den Aufruf von Ressourcen.
• Das Anpassen von Token beschreibt die Informationen, die Sie in Microsoft Entra-Token empfangen können, und wie Sie Token anpassen können.
• Das Konfigurieren von Gruppenansprüchen und App-Rollen in Token beschreibt, wie Ihre Apps mit App-Rollendefinitionen konfiguriert und App-Rollen Sicherheitsgruppen zugewiesen werden.
• Das Erstellen von Apps, die die Identität über Berechtigungen und Zustimmung sichern, bietet eine Übersicht über Berechtigungen und bewährte Methoden für den Zugriff.