Verwalten von Token für Zero Trust

  • Artikel

In der Zero Trust-Anwendungsentwicklung ist es wichtig, die Absicht Ihrer Anwendung und deren Ressourcenzugriffsanforderungen genau zu definieren. Ihre App sollte nur den Zugriff anfordern, der für die Funktion erforderlich ist. Dieser Artikel hilft Ihnen als Entwickler, Sicherheit in Ihre Anwendungen mit ID-Token, Zugriffstoken und Sicherheitstoken zu integrieren, die Ihre App von der Microsoft Identity Platform erhalten kann.

Stellen Sie sicher, dass Ihre Anwendung dem Zero Trust-Prinzip der geringsten Berechtigungen entspricht, und verhindern Sie die Verwendungen, die Ihre Absicht gefährden. Beschränken Sie den Benutzerzugriff mit Just-In-Time- und Just-Enough-Access (JIT/JEA), risikobasierten adaptiven Richtlinien und Datenschutz. Trennen Sie die vertraulichen und leistungsstarken Abschnitte Ihrer App, sodass nur autorisierter Benutzerzugriff auf diese Bereiche gewährt wird. Beschränken Sie Benutzer, die Ihre Anwendung und die Funktionen in Ihrer App verwenden können.

Erstellen Sie möglichst wenige Berechtigungen für die Verwaltung von ID-Token, die sie von der Microsoft Identity Platform empfängt. Die Informationen in den ID-Tokens ermöglichen es Ihnen, zu überprüfen, ob ein Benutzer derjenige ist, der er vorgibt zu sein. Der Benutzer oder seine Organisation kann Authentifizierungsbedingungen angeben, z. B. die Bereitstellung einer MFA, die Verwendung eines verwalteten Geräts und den richtigen Speicherort.

Sorgen Sie dafür, dass Ihre Kunden Autorisierungen für Ihre App verwalten können. Verringern Sie den Aufwand für die Benutzerbereitstellung und die Notwendigkeit manueller Prozesse. Mit der automatischen Benutzerbereitstellung können IT-Administratoren die Erstellung, Pflege und Entfernung von Benutzeridentitäten in Zielidentitätsspeichern automatisieren. Ihre Kunden können Automatisierungen auf Änderungen an Benutzern und Gruppen mit App-Bereitstellung oder HR-gesteuerter Bereitstellung in Microsoft Entra ID basieren.

Verwenden von Tokenansprüchen in Ihren Apps

Verwenden Sie in ID-Token bereitgestellte Ansprüche für die Benutzeroberfläche in Ihrer Anwendung, als Schlüssel in einer Datenbank und um Zugriff auf die Clientanwendung bereitzustellen. Das ID-Token ist die Kernerweiterung, die OpenID Connect (OIDC) für OAuth 2.0 vornimmt. Ihre App kann ID-Token zusammen oder anstelle von Zugriffstoken empfangen.

Im Standardmuster für die Autorisierung von Sicherheitstoken ermöglicht ein ausgestelltes ID-Token der Anwendung den Empfang von Informationen über den Benutzer. Verwenden Sie das ID-Token nicht als Autorisierungsprozess für den Zugriff auf Ressourcen. Der Autorisierungsserver stellt ID-Token aus, die Ansprüche mit Benutzerinformationen enthalten, die Folgendes umfassen.

  • Der Anspruch der Zielgruppe (aud) ist die Client-ID Ihrer App. Akzeptieren Sie nur Token für Ihre API-Client-ID.
  • Der tid Anspruch ist die ID des Mandanten, der das Token ausgestellt hat. Der oid Anspruch ist ein unveränderlicher Wert, der den Benutzer eindeutig identifiziert. Verwenden Sie die eindeutige Kombination der Ansprüche tid und oid als Schlüssel, wenn Sie dem Benutzer Daten zuordnen müssen. Sie können diese Anspruchswerte verwenden, um Ihre Daten wieder mit der ID des Benutzers in Microsoft Entra ID zu verbinden.
  • Der sub Anspruch ist ein unveränderlicher Wert, der den Benutzer eindeutig identifiziert. Der Subjektanspruch ist ebenfalls eindeutig für Ihre Anwendung. Wenn Sie den sub Anspruch zum Zuordnen von Daten mit dem Benutzer verwenden, ist es unmöglich, aus Ihren Daten zu wechseln und sie mit einem Benutzer in Microsoft Entra ID zu verbinden.

Ihre Apps können den openid Bereich verwenden, um ein ID-Token von der Microsoft Identity Platform anzufordern. Der OIDC-Standard steuert den openid Bereich zusammen mit dem Format und dem Inhalt des ID-Tokens. OIDC gibt die folgenden Bereiche an:

  • Verwenden Sie den openid Bereich, um sich beim Benutzer anzumelden und dem ID-Token einen sub Anspruch hinzuzufügen. Diese Bereiche stellen eine Benutzer-ID bereit, die für die App und den Benutzer eindeutig ist und den UserInfo-Endpunkt aufruft.
  • Der email Bereich fügt dem ID-Token einen email Anspruch hinzu, der die E-Mail-Adresse des Benutzers enthält.
  • Der profile Bereich fügt dem ID-Token Ansprüche mit grundlegenden Profilattributen des Benutzers (Name, Benutzername) hinzu.
  • Der offline_access Bereich ermöglicht der App den Zugriff auf Benutzerdaten, auch wenn der Benutzer nicht vorhanden ist.

Die Microsoft Authentication Library (MSAL) fügt jeder Tokenanforderung immer die OpenID, E-Mail und profile Bereiche hinzu. Daher gibt MSAL immer ein ID-Token und ein Zugriffstoken für jeden Aufruf von AcquireTokenSilent oder AcquireTokenInteractive zurück. MSAL fordert immer den offline_access Bereich an. Die Microsoft Identity Platform gibt immer den offline_access Bereich zurück, auch wenn die anfordernde App den offline_access Bereich nicht angibt.

Microsoft verwendet den OAuth2-Standard, um Zugriffstoken auszugeben. Der OAuth2-Standard besagt, dass Sie ein Token erhalten, aber es gibt nicht das Tokenformat an oder was im Token enthalten sein muss. Wenn Ihre Anwendung auf eine Ressource zugreifen muss, die von Microsoft Entra ID geschützt wird, sollte sie einen Bereich verwenden, den die Ressource definiert hat.

Beispielsweise definiert Microsoft Graph den User.Read-Bereich, der die Anwendung autorisiert, auf das vollständige Benutzerprofil des aktuellen Benutzers und den Namen des Mandanten zuzugreifen. Microsoft Graph definiert Berechtigungen für den gesamten Funktionsumfang, der in dieser API verfügbar ist.

Bei der Autorisierung gibt die Microsoft Identity Platform ein Zugriffstoken für Ihre Anwendung zurück. Wenn Sie die Ressource aufrufen, stellt Ihre App dieses Token als Teil des Autorisierungsheaders der HTTP-Anforderung an die API bereit.

Verwalten von Tokenlebensdauern

Anwendungen können eine Sitzung für einen Benutzer erstellen, nachdem die Authentifizierung erfolgreich mit Microsoft Entra ID abgeschlossen wurde. Die Benutzersitzungsverwaltung steuert, wie häufig ein Benutzer eine erneute Authentifizierung benötigt. Seine Rolle bei der Beibehaltung eines explizit überprüften Benutzers vor der App mit den richtigen Berechtigungen und für den richtigen Zeitraum ist entscheidend. Die Sitzungsdauer muss auf dem exp Anspruch im ID-Token basieren. Der exp Anspruch ist der Zeitpunkt, zu dem das ID-Token abläuft, und die Zeit, nach der Sie das Token nicht mehr zum Authentifizieren des Benutzers verwenden können.

Beachten Sie immer die Tokenlebensdauer, wie in der Tokenantwort für Zugriffstoken angegeben, oder den exp Anspruch im ID-Token. Bedingungen, die die Tokenlebensdauer steuern, können die Anmeldehäufigkeit für ein Unternehmen umfassen. Ihre Anwendung kann die Tokenlebensdauer nicht konfigurieren. Sie können keine Tokenlebensdauer anfordern.

Im Allgemeinen müssen Token gültig und nicht abgelaufen sein. Der Anspruch der Zielgruppe (aud) muss mit Ihrer Client-ID übereinstimmen. Stellen Sie sicher, dass das Token von einem vertrauenswürdigen Aussteller stammt. Wenn Sie über eine mehrinstanzenfähige API verfügen, können Sie filtern, damit nur bestimmte Mandanten Ihre API aufrufen können. Stellen Sie sicher, dass Sie die Lebensdauer des Tokens erzwingen. Überprüfen Sie die nbf Ansprüche (nicht vorher) und die exp Ansprüche (Ablauf), um sicherzustellen, dass sich die aktuelle Zeit innerhalb der Werte dieser beiden Ansprüche befindet.

Zielen Sie nicht auf außergewöhnlich lange oder kurze Sitzungsdauern ab. Lassen Sie die erteilte ID-Tokenlebensdauer diese Entscheidung steuern. Wenn die Sitzungen Ihrer App über die Tokengültigkeit hinaus aktiv bleiben, verstoßen sie gegen die Regeln, Richtlinien und Bedenken, die einen IT-Administrator dazu veranlasst haben, eine Tokengültigkeitsdauer festzulegen, um nicht autorisierten Zugriff zu verhindern. Kurze Sitzungen beeinträchtigen die Benutzererfahrung und erhöhen nicht unbedingt den Sicherheitsstatus. Beliebte Frameworks wie ASP.NET ermöglichen es Ihnen, Sitzungs- und Cookie-Timeouts aus dem Ablaufzeitpunkt des ID-Tokens der Microsoft Entra-ID festzulegen. Nach Ablaufzeit des Identitätsanbieters wird sichergestellt, dass die Sitzungen des Benutzers nie länger sind als die Richtlinien, die der Identitätsanbieter vorgibt.

Token zwischenspeichern und aktualisieren

Denken Sie daran, Token entsprechend zwischenzuspeichern. MSAL speichert Token automatisch zwischen, aber die Token verfügen über Lebensdauern. Verwenden Sie Token über die vollständige Länge ihrer Lebensdauer, und speichern Sie sie entsprechend zwischen. Wenn Sie wiederholt nach demselben Token fragen, führt die Drosselung dazu, dass Ihre Anwendung weniger reaktionsfähig wird. Wenn Ihre App die Tokenausstellung missbraucht, verlängert sich die Zeit, die für das Ausgeben neuer Token an Ihre App erforderlich ist.

MSAL-Bibliotheken verwalten die Details des OAuth2-Protokolls, einschließlich der Mechanismen zum Aktualisieren von Token. Wenn Sie MSAL nicht verwenden, stellen Sie sicher, dass Ihre ausgewählte Bibliothek Aktualisierungstoken effektiv verwendet.

Wenn Ihr Client ein Zugriffstoken für den Zugriff auf eine geschützte Ressource abruft, erhält er auch ein Aktualisierungstoken. Verwenden Sie das Aktualisierungstoken, um neue Zugriffs-/Aktualisierungstoken-Paare abzurufen, nachdem das aktuelle Zugriffstoken abgelaufen ist. Verwenden Sie Aktualisierungstoken, um zusätzliche Zugriffstoken für andere Ressourcen abzurufen. Aktualisierungstoken sind an eine Kombination aus Benutzer und Client gebunden (nicht an eine Ressource oder einen Mandanten). Sie können ein Aktualisierungstoken nutzen, um Zugriffstoken für eine beliebige Kombination von Ressourcen und Mandanten zu beziehen, für die Ihre Anwendung berechtigt ist.

Verwalten von Tokenfehlern und Bugs

Ihre Anwendung sollte niemals versuchen, den Inhalt eines Zugriffstokens zu überprüfen, zu decodieren, zu evaluieren, zu interpretieren oder zu untersuchen. Diese Vorgänge unterliegen der Verantwortung der Ressourcen-API. Wenn Ihre App versucht, den Inhalt eines Zugriffstokens zu untersuchen, ist es höchstwahrscheinlich, dass Ihre Anwendung unterbrochen wird, wenn die Microsoft Identity Platform verschlüsselte Token ausgibt.

In seltenen Fällen kann es beim Tokenabruf zu einem Fehler aufgrund eines Ausfalls des Netzwerks, der Infrastruktur oder des Authentifizierungsdiensts kommen. Erhöhen Sie die Ausfallsicherheit der Authentifizierung in Ihrer Anwendung, wenn ein Tokenerwerbsfehler auftritt, indem Sie die folgenden bewährten Methoden ausführen:

  • Token lokal zwischenspeichern und mit Verschlüsselung sichern.
  • Übertragen Sie keine Sicherheitsartefakte wie Token auf nicht unsicheren Kanälen.
  • Verstehen und Reagieren auf Ausnahmen und Dienstantworten vom Identitätsanbieter.

Entwickler haben häufig Fragen zum Suchen innerhalb von Token zum Debuggen von Problemen, z. B. beim Empfang eines 401-Fehlers beim Aufrufen der Ressource. Da verschlüsselte Token verhindern, dass Sie innerhalb eines Zugriffstokens suchen, benötigen Sie Alternativen für diese Suchen. Für das Debuggen stellt die Tokenantwort, die das Zugriffstoken enthält, die benötigten Informationen bereit.

Prüfen Sie in Ihrem Code auf Fehlerklassen, statt auf einzelne Fehlerfälle. Behandeln Sie beispielsweise die erforderliche Benutzerinteraktion anstelle einzelner Fehler, bei denen das System keine Berechtigung erteilt hat. Da Sie diese einzelnen Fälle möglicherweise nicht erfassen, ist es besser, nach einem Klassifizierer wie Benutzerinteraktion zu suchen, anstatt nach einzelnen Fehlercodes.

Möglicherweise müssen Sie auf AcquireTokenInteractive Ansprüche zurückgreifen und solche bereitstellen, die der AcquireTokenSilent Aufruf erfordert. Dadurch wird eine effektive Verwaltung der interaktiven Anforderung sichergestellt.

Nächste Schritte