Freigeben über

Anpassen von Token

  • Artikel

Als Entwickler besteht Ihre primäre Interaktion mit Microsoft Entra ID in der Anforderung eines Tokens, um den Benutzer zu identifizieren. Sie fordern auch ein Token an, um eine Autorisierung zum Aufrufen einer Web-API zu erhalten. Das Web API-Token bestimmt, was diese API tun kann, wenn sie eine bestimmte Anforderung ausführt. In diesem Artikel erfahren Sie mehr über die Informationen, die Sie in Token empfangen können, und wie Sie Token anpassen können. Diese bewährten Methoden für Zero Trust-Entwickler verbessern Flexibilität und Kontrolle und erhöhen gleichzeitig die Anwendungssicherheit mit geringsten Berechtigungen.

Ihre Gründe für die Anpassung Ihrer Anwendungstoken hängen vom Prozess ab, den Sie verwenden, um eine differenziertere Autorisierung in Ihren Anwendungen und APIs zu fördern. Sie können beispielsweise unterschiedliche Benutzerrollen, Zugriffsebenen und Funktionen in Ihrer App haben, die auf Informationen von Token basieren.

Die Microsoft Graph-API bietet einen robusten Satz von Verzeichnisinformationen und -daten in Microsoft 365. Sie können ein differenziertes und umfassendes Autorisierungssystem entwickeln, indem Sie auf den Daten in Microsoft Graph aufbauen. Sie können beispielsweise auf Informationen aus der Gruppenmitgliedschaft des Benutzers, detaillierte Profildaten, SharePoint und Outlook zugreifen, um sie in Ihren Autorisierungsentscheidungen zu verwenden. Sie können auch Autorisierungsdaten in das Token aus Microsoft Entra ID einschließen.

Autorisierung auf Anwendungsebene

It-Spezialisten können die Autorisierung auf App-Ebene hinzufügen, ohne das Token anzupassen oder den Entwickler einen Code hinzufügen zu lassen.

IT-Spezialisten können verhindern, dass Token an eine beliebige App im Mandanten ausgegeben werden, indem sie die erforderliche Kennzeichnung der Benutzerzuweisung verwenden, um sicherzustellen, dass sich nur eine Gruppe von Benutzern bei der Anwendung anmelden kann. Ohne diese Kennzeichnung können alle Benutzer in einem Mandanten auf die Anwendung zugreifen. Mit dieser Kennzeichnung können nur zugewiesene Benutzer und Gruppen auf die Anwendung zugreifen. Wenn ein zugewiesener Benutzer auf die App zugreift, empfängt die App ein Token. Wenn der Benutzer keine Zuweisung hat, erhält die App kein Token. Denken Sie daran, Tokenanforderungen, die keine Token empfangen, immer ordnungsgemäß zu behandeln.

Tokenanpassungsmethoden

Es gibt zwei Möglichkeiten zum Anpassen von Token: optionale Ansprüche und Anspruchszuordnung.

Optionale Ansprüche

Optionale Ansprüche geben an, welche Ansprüche Microsoft Entra-ID an Ihre Anwendung in Token gesendet werden soll. Sie können optionale Ansprüche zu folgenden Zwecken verwenden:

  • Auswählen weiterer Ansprüche, die in Token für Ihre Anwendung aufgenommen werden sollen
  • Ändern des Verhaltens von Ansprüchen, die von Microsoft Identity Platform in Token zurückgegeben werden.
  • Hinzufügen und Zugreifen auf benutzerdefinierte Ansprüche für Ihre Anwendung

Optionale Ansprüche hängen vom Anwendungsregistrierungsobjekt mit einem definierten Schema ab. Sie gelten für die Anwendung, unabhängig davon, wo sie ausgeführt wurde. Wenn Sie eine mehrinstanzenfähige Anwendung schreiben, funktionieren optionale Ansprüche gut, da sie für jeden Mandanten in Microsoft Entra ID konsistent sind. Beispielsweise ist eine IP-Adresse nicht mandantenspezifisch, während eine Anwendung über eine IP-Adresse verfügt.

Standardmäßig können sich Gastbenutzer in einem Mandanten auch bei Ihrer App anmelden. Wenn Sie Gastbenutzer blockieren möchten, melden Sie sich für den optionalen Anspruch (acct) an. Wenn es 1 ist, hat der Benutzer eine Gastklassifizierung. Wenn Sie Gäste blockieren möchten, blockieren Sie Token mit acct==1.

Anspruchszuordnungsrichtlinien

Ein Richtlinienobjekt stellt in Microsoft Entra ID eine Reihe von Regeln dar, die für einzelne Anwendungen oder alle Anwendungen in einer Organisation gelten. Eine Anspruchszuordnungsrichtlinie modifiziert die Ansprüche in Token, die Microsoft Entra ID für bestimmte Anwendungen ausgegeben hat.

Sie verwenden die Anspruchszuordnung für mandantenspezifische Informationen ohne Schema (z. B. EmployeeID, DivisionName). Die Anspruchszuordnung gilt auf dienstprinzipaler Ebene, die der Mandantenadministrator steuert. Die Anspruchszuordnung entspricht der Unternehmens-App oder dem Dienstprinzipal für diese Anwendung. Jeder Mandant kann über eine eigene Anspruchszuordnung verfügen.

Wenn Sie eine Geschäftsanwendung entwickeln, können Sie sich genau ansehen, was Ihr Mandant tut (welche spezifischen Ansprüche Ihr Mandant verfügbar hat, die Sie in Ihrem Token verwenden können). Wenn eine Organisation z. B. über die Eigenschaft „Abteilungsname” eines Benutzers (nicht über ein Standardfeld in Microsoft Entra ID) in seinem lokalen Active Directory verfügt, können Sie Microsoft Entra Connect verwenden, um sie mit Microsoft Entra ID zu synchronisieren.

Sie können eines der Standarderweiterungsattribute verwenden, um diese Informationen zu enthalten. Sie können Ihr Token mit einem Abteilungsnamenanspruch definieren, den Sie aus der entsprechenden Erweiterung erstellen können (auch wenn es nicht für jeden Mandanten gilt). Beispielsweise fügt eine Organisation ihren Abteilungsnamen in Erweiterungsattribut 13 ein.

Mit der Anspruchszuordnung können Sie es für einen anderen Mandanten verwenden, der seinen Divisionsnamen in Attribut sieben einfügt.

Planen der Tokenanpassung

Welches Token Sie anpassen, hängt von Ihrer Art der Anwendung ab: Clientanwendung oder API. Es gibt keinen Unterschied, was Sie tun können, um Ihr Token anzupassen. Was Sie in das Token einfügen können, ist immer gleich. Welches Token Sie anpassen möchten, hängt davon ab, welches Token Ihre App verwendet.

Anpassen von ID-Token

Wenn Sie eine Clientanwendung entwickeln, passen Sie das ID-Token an, da es sich um das Token handelt, das Sie zum Identifizieren des Benutzers anfordern. Ein Token gehört zu Ihrer App, wenn der Zielgruppenanspruch (aud) im Token mit der Client-ID Ihrer Anwendung übereinstimmt. Stellen Sie für eine Clientanwendung, die APIs aufruft, sie aber nicht implementiert, sicher, dass Sie nur das ID-Token Ihrer App anpassen.

Mit Azure Portal und Microsoft Graph-API können Sie auch das Zugriffstoken für Ihre App anpassen, diese Anpassungen haben jedoch keine Auswirkungen. Sie können kein Zugriffstoken für eine API anpassen, die Sie nicht besitzen. Denken Sie daran, dass Ihre App nicht versuchen darf, ein Zugriffstoken zu decodieren oder zu prüfen, das Ihre Client-App als Autorisierung zum Aufrufen einer API empfängt.

Anpassen von Zugriffstoken

Wenn Sie eine API entwickeln, passen Sie das Zugriffstoken an, da Ihre API Zugriffstoken als Teil des Aufrufs des Clients an Ihre API empfängt.

Clientanwendungen passen immer das ID-Token an, das sie empfangen, um den Benutzer zu identifizieren. APIs passen die Zugriffstoken an, welche die API als Teil des Aufrufs der API empfängt.

Gruppen- und App-Rollen

Eine der am häufigsten verwendeten Autorisierungstechniken besteht darin, den Zugriff auf die Gruppenmitgliedschaft eines Benutzers oder die zugewiesenen Rollen zu basieren. Konfigurieren von Gruppenansprüchen und App-Rollen in Token zeigt, wie Sie Ihre Apps mit App-Rollendefinitionen konfigurieren und Sicherheitsgruppen zu App-Rollen zuweisen. Diese Methoden tragen dazu bei, Flexibilität und Kontrolle zu verbessern und gleichzeitig die Zero Trust-Sicherheit der Anwendung mit minimalen Berechtigungen zu erhöhen.

Nächste Schritte