Sichern von Anwendungen und APIs durch Überprüfen von Ansprüchen

  • Artikel

Die Interaktion mit Token ist ein zentraler Bestandteil des Erstellens von Anwendungen zum Autorisieren von Benutzern. In Übereinstimmung mit dem Zero Trust-Prinzip für den geringstprivilegierten Zugriff ist es wichtig, dass Anwendungen die Werte bestimmter Ansprüche überprüfen, die im Zugriffs-Token vorhanden sind, wenn die Autorisierung ausgeführt wird.

Mithilfe der anspruchsbasierten Autorisierung können Anwendungen sicherstellen, dass das Token die richtigen Werte für Dinge wie den Mandanten, den Antragsteller und den Akteur enthält, die im Token vorhanden sind. Allerdings kann die anspruchsbasierte Autorisierung angesichts der verschiedenen zu verwendenden Methoden und Szenarien, die nachverfolgt werden sollen, komplex erscheinen. Dieser Artikel soll den anspruchsbasierten Autorisierungsprozess vereinfachen, damit Sie sicherstellen können, dass Ihre Anwendungen die sichersten Methoden einhalten.

Um sicherzustellen, dass Ihre Autorisierungslogik sicher ist, müssen Sie die folgenden Informationen in Ansprüchen überprüfen:

  • Die entsprechende Zielgruppe wird für das Token angegeben.
  • Die Mandanten-ID des Tokens entspricht der ID des Mandanten, in dem Daten gespeichert werden.
  • Der Antragsteller des Tokens ist angemessen.
  • Der Akteur (Client-App) ist autorisiert.

Hinweis

Zugriffs-Token werden nur in den Web-APIs überprüft, für die sie von einem Client abgerufen wurden. Der Client sollte Zugriffs-Token nicht überprüfen.

Weitere Informationen zu den in diesem Artikel erwähnten Ansprüchen finden Sie unter Microsoft Identity Platform-Zugriffstoken.

Überprüfen der Zielgruppe

Der Anspruch aud gibt die vorgesehene Zielgruppe des Tokens an. Bevor Sie Ansprüche überprüfen, müssen Sie immer überprüfen, ob der Wert des Anspruchs aud im Zugriffs-Token mit der Web-API übereinstimmt. Der Wert kann davon abhängen, wie der Client das Token angefordert hat. Die Zielgruppe im Zugriffs-Token hängt vom Endpunkt ab:

  • Bei v2.0-Token ist die Zielgruppe die Client-ID der Web-API. Es handelt sich um eine GUID.
  • Bei v1.0-Token ist die Zielgruppe eine der appID-URIs, die in der Web-API deklariert sind, die das Token überprüft. Beispiel: api://{ApplicationID} oder ein eindeutiger Name, der mit einem Domänennamen beginnt (wenn der Domänenname einem Mandanten zugeordnet ist).

Weitere Informationen zum appID-URI einer Anwendung finden Sie unter Anwendungs-ID-URI.

Überprüfen des Mandanten

Überprüfen Sie immer, ob der tid-Wert in einem Token mit der Mandanten-ID übereinstimmt, die zum Speichern von Daten mit der Anwendung verwendet wird. Wenn Informationen für eine Anwendung im Kontext eines Mandanten gespeichert werden, sollte erst später im selben Mandanten erneut darauf zugegriffen werden. Lassen Sie niemals zu, dass auf Daten in einem Mandanten über einen anderen Mandanten zugegriffen werden kann.

Die Überprüfung des Mandanten ist nur der erste Schritt, und die in diesem Artikel beschriebenen Prüfungen zu Thema und Akteur sind weiterhin erforderlich. Wenn Sie beabsichtigen, alle Benutzer in einem Mandanten zu autorisieren, wird dringend empfohlen, diese Benutzer explizit zu einer Gruppe hinzuzufügen und basierend auf der Gruppe zu autorisieren. Wenn Sie beispielsweise nur die Mandanten-ID und das Vorhandensein eines oid-Anspruchs überprüfen, kann Ihre API versehentlich alle Dienstprinzipale in diesem Mandanten zusätzlich zu Benutzern autorisieren.

Überprüfen des Antragstellers

Ermitteln Sie, ob der Antragsteller des Tokens, z. B. der Benutzer (oder die Anwendung selbst für ein reines App-Token), autorisiert ist.

Sie können entweder nach bestimmten sub- oder oid-Ansprüchen suchen.

Oder:

Sie können mit den Ansprüchen roles, groups und wids überprüfen, ob der Antragsteller zu einer entsprechenden Rolle oder Gruppe gehört. Verwenden Sie beispielsweise die unveränderlichen Anspruchswerte tid und oid als kombinierten Schlüssel für Anwendungsdaten, und bestimmen Sie, ob Benutzer*innen Zugriff gewährt werden soll.

Die Ansprüche roles, groups oder wids können auch verwendet werden, um zu bestimmen, ob der Antragsteller über die Berechtigung zum Ausführen eines Vorgangs verfügt. Beispielsweise können Administrator*innen über die Berechtigung zum Schreiben in eine API verfügen, nicht aber normale Benutzer*innen, oder Benutzer*innen können sich in einer Gruppe befinden, die eine Aktion ausführen darf. Der Anspruch wid gibt die mandantenweiten Rollen an, die dem Benutzer von den in den integrierten Microsoft Entra-Rollen vorhandenen Rollen zugewiesen wurden. Weitere Informationen finden Sie unter Integrierte Rollen in Microsoft Entra.

Warnung

Verwenden Sie niemals die Ansprüche email, preferred_username oder unique_name zum Speichern oder zum Ermitteln, ob Benutzer in einem Zugriffs-Token Zugriff auf Daten haben sollen. Diese Ansprüche sind nicht eindeutig und können von Mandantenadministratoren oder manchmal Benutzern kontrolliert werden, was sie für Autorisierungsentscheidungen ungeeignet macht. Sie sind nur für Anzeigezwecke verwendbar. Verwenden Sie den Anspruch upn auch nicht für die Autorisierung. Obwohl der Benutzerprinzipalname eindeutig ist, ändert er sich häufig im Laufe der Lebensdauer eines Benutzerprinzipals, wodurch er für die Autorisierung unzuverlässig ist.

Überprüfen des Akteurs

Eine Client-Anwendung, die im Namen eines Benutzers (als Akteur bezeichnet) agiert, muss ebenfalls autorisiert werden. Verwenden Sie den Anspruch scp (Bereich), um zu überprüfen, ob die Anwendung über die Berechtigung zum Ausführen eines Vorgangs verfügt. Die Berechtigungen in scp sollten auf das beschränkt werden, was der Benutzer tatsächlich benötigt, und die Prinzipien der geringsten Rechte befolgen.

Es gibt jedoch bekannte Szenarien, in denen scp nicht im Token vorhanden ist: Sie sollten prüfen, ob der scp-Anspruch für die folgenden Szenarien nicht vorhanden ist:

  • Daemon-Apps/Nur-App-Berechtigung
  • ID-Token

Weitere Informationen zu Bereichen und Berechtigungen finden Sie unter Bereiche und Berechtigungen auf der Microsoft Identity Platform.

Hinweis

Eine Anwendung kann reine App-Token verarbeiten (Anforderungen von Anwendungen ohne Benutzer*in, z. B. Daemon-Apps) und eine bestimmte Anwendung über mehrere Mandanten hinweg autorisieren, anstatt einzelne Dienstprinzipal-IDs zu verwenden. In diesem Fall kann der Anspruch appid (für v1.0-Token) oder der Anspruch azp (für v2.0-Token) für die Autorisierung des Antragstellers verwendet werden. Bei Verwendung dieser Ansprüche muss die Anwendung jedoch sicherstellen, dass das Token direkt für die Anwendung ausgestellt wurde, indem sie den optionalen Anspruch idtyp überprüft. Nur Token vom Typ app können auf diese Weise autorisiert werden, da delegierte Benutzer-Token möglicherweise von anderen Entitäten als der Anwendung abgerufen werden können.

Nächste Schritte