Freigeben über

Verwalten von Token für Zero Trust

In der Zero Trust-Anwendungsentwicklung ist es wichtig, die Absicht Ihrer Anwendung und deren Ressourcenzugriffsanforderungen speziell 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 Verwendung in der Weise, wie Sie 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. Gewähren Sie nur autorisierten Benutzerzugriff auf diese Bereiche. Beschränken Sie Benutzer, die Ihre Anwendung und die Funktionen in Ihrer App verwenden können.

Integrieren Sie Prinzipien des geringsten Privilegs in die Verwaltung von ID-Token, die die Microsoft Identity Platform empfängt. Mithilfe von Informationen in ID-Token können Sie überprüfen, ob ein Benutzer die Person ist, für die er anspruchsberechtigt ist. Der Benutzer oder seine Organisation kann Authentifizierungsbedingungen wie MFA, verwaltete Geräte und korrekte Speicherorte angeben.

Sorgen Sie dafür, dass Ihre Kunden Autorisierungen für Ihre App verwalten können. Verringern Sie den Benutzererstellungs- und Konfigurationsaufwand und manuelle Prozesse. Durch die automatische Benutzerbereitstellung können IT-Administratoren die Erstellung, Wartung und Entfernung von Benutzeridentitäten in Zielidentitätsspeichern automatisieren. Ihre Kunden können die Automatisierung auf Änderungen an Benutzern und Gruppen mit App-Bereitstellung oder hrgesteuerter Bereitstellung in Microsoft Entra ID basieren.

Verwenden Sie Token-Ansprüche in Ihren Apps

Verwenden Sie Ansprüche in ID-Token für die Benutzererfahrung innerhalb Ihrer Anwendung als Schlüssel in einer Datenbank. Bieten Sie Zugriff auf die Clientanwendung. Das ID-Token ist die Kernerweiterung, die OpenID Connect (OIDC) an OAuth 2.0 macht. 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 gibt ID-Token aus, die Ansprüche mit Benutzerinformationen enthalten, die Folgendes enthalten.

  • 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 tid- und oid-Ansprüche als Schlüssel, wenn Sie dem Benutzer Daten zuordnen müssen. Verwenden Sie diese Anspruchswerte, 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 Anspruch ist auch für Ihre Anwendung einzigartig. Wenn Sie den sub Anspruch zur Zuordnung von Daten mit dem Benutzer verwenden, ist es unmöglich, von Ihren Daten aus auf einen Benutzer in Microsoft Entra ID zu schließen.

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 den Benutzer anzumelden und dem ID-Token einen sub Claim 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 Bereich zurück offline_access , 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 die User.Read-Berechtigung, die die Anwendung dazu berechtigt, 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 Token-Lebenszeiten

Anwendungen können eine Sitzung für einen Benutzer erstellen, nachdem die Authentifizierung erfolgreich mit der Microsoft Entra-ID abgeschlossen wurde. Die Benutzersitzungsverwaltung steuert, wie häufig ein Benutzer wiederholte 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 oder den exp Anspruch im ID-Token angegeben. 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 Token-Lebensdauer anfordern.

Stellen Sie im Allgemeinen sicher, dass Token gültig und nicht abgelaufen sind. 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-(Ablauf)-Ansprüche, um sicherzustellen, dass die aktuelle Zeit innerhalb der Werte dieser beiden Ansprüche liegt.

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 Ihnen die Einstellung von Sitzungs- und Cookie-Timeouts aus der Ablaufzeit des Microsoft Entra ID-Tokens. Befolgen Sie die Ablaufzeit des Identitätsanbieters, um sicherzustellen, dass die Sitzungen Ihres Benutzers nie länger sind als die Richtlinien, die der Identitätsanbieter vorgibt.

Cache- und Aktualisierungstoken

Denken Sie daran, Token entsprechend zwischenzuspeichern. MSAL speichert Tokens automatisch im Cache, aber die Tokens haben eine Lebensdauer. Verwenden Sie Token während ihrer gesamten Lebensdauer und zwischenspeichern Sie sie entsprechend. 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, wird die Zeit zum Ausgeben neuer Token für Ihre App verlängert.

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 die von Ihnen gewählte Bibliothek Aktualisierungstoken effektiv nutzt.

Wenn Ihr Client ein Zugriffstoken für den Zugriff auf eine geschützte Ressource erwirbt, empfängt er ein Aktualisierungstoken. Verwenden Sie das Aktualisierungstoken, um neue Zugriffs-/Aktualisierungstokenpaare abzurufen, nachdem das aktuelle Zugriffstoken abgelaufen ist. Verwenden Sie Aktualisierungstoken, um zusätzliche Zugriffstoken für andere Ressourcen zu erhalten. Aktualisierungstoken sind an eine Kombination aus Benutzer und Client gebunden (nicht an eine Ressource oder einen Mandanten). Sie können ein Aktualisierungstoken verwenden, um Zugriffstoken in einer beliebigen Kombination von Ressourcen und Mandanten abzurufen, in denen Ihre App über Berechtigungen verfügt.

Verwalten von Tokenfehlern und Bugs

Ihre Anwendung sollte niemals versuchen, den Inhalt eines Zugriffstokens zu überprüfen, zu decodieren, zu untersuchen, zu interpretieren oder zu analysieren. Für diese Vorgänge ist ausschließlich die Ressourcen-API verantwortlich. 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.

Selten schlägt ein Aufruf zum Abrufen eines Tokens aufgrund von Problemen wie Netzwerk-, Infrastruktur- oder Authentifizierungsdienstfehlern oder Ausfall fehl. Erhöhen Sie die Ausfallsicherheit der Authentifizierung in Ihrer Anwendung, wenn ein Tokenerwerbsfehler auftritt, indem Sie die folgenden bewährten Methoden ausführen:

  • Lokal zwischenspeichern und sichern Sie Token mit Verschlüsselung.
  • Übergeben 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 Fehlers von 401 beim Aufrufen der Ressource. Da verschlüsselte Token verhindern, dass Sie innerhalb eines Zugriffstokens suchen, müssen Sie Alternativen zum Suchen innerhalb von Zugriffstoken finden. Für das Debuggen stellt die Tokenantwort, die das Zugriffstoken enthält, die benötigten Informationen bereit.

Überprüfen Sie in Ihrem Code anstelle einzelner Fehlerfälle auf Fehlerklassen. Behandeln Sie beispielsweise die erforderliche Benutzerinteraktion anstelle einzelner Fehler, wenn das System keine Berechtigung erteilt. Da Sie diese einzelnen Fälle möglicherweise verpassen, ist es besser, nach einem Klassifizierer wie Benutzerinteraktion zu suchen, anstatt einzelne Fehlercodes einzugraben.

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

Nächste Schritte

  • Last updated on