Glossar: Microsoft Identitätsplattform

Diese Bedingungen werden angezeigt, wenn Sie unsere Dokumentation, das Microsoft Entra Admin Center, unsere Authentifizierungsbibliotheken und die Microsoft Graph-API verwenden. Einige Begriffe sind spezifisch für Microsoft, während andere mit Protokollen wie OAuth oder anderen Technologien zusammenhängen, die Sie mit der Microsoft Identitätsplattform verwenden.

Zugriffstoken

Eine Art von Sicherheitstoken. Wird von einem Autorisierungsserver ausgestellt und von einer Clientanwendung für den Zugriff auf einen geschützten Ressourcenserver verwendet. Das Token liegt in der Regel in Form eines JSON Web Token (JWT) vor und stellt die Autorisierung dar, die dem Client durch den Ressourcenbesitzer für eine angeforderte Zugriffsstufe gewährt wurde. Das Token enthält alle geltenden Ansprüche für den Antragsteller und kann von der Clientanwendung beim Zugriff auf eine bestimmte Ressource als eine Art von Anmeldeinformationen verwendet werden. Der Ressourcenbesitzer muss somit gegenüber dem Client keine Anmeldeinformationen angeben.

Zugriffstoken sind nur für kurze Zeit gültig und können nicht widerrufen werden. Ein Autorisierungsserver kann auch ein Aktualisierungstoken ausgeben, wenn das Zugriffstoken ausgestellt wird. Aktualisierungstoken werden in der Regel nur für vertrauliche Clientanwendungen bereitgestellt.

Zugriffstoken werden abhängig von den vorgelegten Anmeldeinformationen gelegentlich auch als „Benutzer- und App-Token“ oder als „ App-exklusives Token“ bezeichnet. Beispielverwendungsszenarien für die Clientanwendung:

• Autorisierungsgewährung mit Autorisierungscode: In diesem Fall wird der Endbenutzer zunächst als Ressourcenbesitzer authentifiziert, und die Autorisierung für den Ressourcenzugriff wird an den Client delegiert. Der Client wird später beim Beziehen des Zugriffstokens authentifiziert. Das Token wird gelegentlich spezifischer als Benutzer- und App-Token bezeichnet, da es sowohl den Benutzer, der die Clientanwendung autorisiert hat, als auch die Anwendung darstellt.
• Autorisierungsgewährung mit Clientanmeldeinformationen: In diesem Fall stellt der Client die einzige Authentifizierung (ohne Authentifizierung/Autorisierung des Ressourcenbesitzers) bereit, weshalb das Token gelegentlich als App-exklusives Token bezeichnet wird.

Weitere Informationen finden Sie in der Zugriffstokenreferenz.

Akteur

Eine andere Benennung für die Clientanwendung. Der Akteur ist die Partei, die im Namen eines Antragstellers (Ressourcenbesitzer) tätig ist.

Anwendungs-ID (Client)

Die Anwendungs-ID oder Client-ID ist ein Wert, den die Microsoft Identitätsplattform Ihrer Anwendung zugeweist, wenn Sie sie in Microsoft Entra ID registrieren. Die Anwendungs-ID ist ein GUID-Wert, der die Anwendung und seine Konfiguration innerhalb der Identitätsplattform eindeutig identifiziert. Sie fügen die App-ID zum Code Ihrer Anwendung hinzu, und Authentifizierungsbibliotheken enthalten den Wert in ihren Anforderungen an die Identitätsplattform zur Anwendungslaufzeit. Die Anwendungs-ID (Client) ist kein Geheimnis – verwenden Sie sie nicht als Kennwort oder andere Anmeldeinformation.

Anwendungsmanifest

Ein Anwendungsmanifest ist ein Feature, das eine JSON-Darstellung der Identitätskonfiguration der Anwendung generiert. Diese wird als Mechanismus für die Aktualisierung der zugehörigen Entitäten Anwendung und Dienstprinzipal verwendet. Ausführlichere Informationen finden Sie unter Grundlegendes zum Microsoft Entra-Anwendungsmanifest.

Anwendungsobjekt

Wenn Sie eine Anwendung registrieren bzw. aktualisieren, werden sowohl ein Anwendungsobjekt als auch ein entsprechendes Dienstprinzipalobjekt für den Mandanten erstellt bzw. aktualisiert. Das Anwendungsobjekt definiert die Identitätskonfiguration der Anwendung global (also für alle Mandanten, auf die es Zugriff hat) und stellte eine Vorlage bereit, von der die entsprechenden Dienstprinzipalobjekte für die lokale Verwendung zur Laufzeit (in einem bestimmten Mandanten) abgeleitet werden.

Weitere Informationen finden Sie unter Anwendungsobjekte und Dienstprinzipalobjekte.

Anwendungsregistrierung

Um einer Anwendung die Integration in Microsoft Entra ID sowie die Delegierung von Identitäts- und Zugriffsverwaltungsfunktionen an Microsoft Entra ID zu ermöglichen, muss sie bei einem Microsoft Entra-Mandanten registriert werden. Wenn Sie Ihre Anwendung mit Microsoft Entra ID registrieren, stellen Sie eine Identitätskonfiguration für Ihre Anwendung bereit, sodass sie in Microsoft Entra ID integriert werden kann und folgende Features verwenden kann:

• Stabile Verwaltung von einmaligem Anmelden mithilfe der Microsoft Entra-Identitätsverwaltung und der OpenID Connect-Protokollimplementierung
• Vermittelter Zugriff auf geschützte Ressourcen durch Clientanwendungen über den OAuth 2.0-Autorisierungsserver
• Consent Framework zum Verwalten des Clientzugriffs auf geschützte Ressourcen auf der Grundlage der Ressourcenbesitzerautorisierung

Weitere Informationen finden Sie unter Integrieren von Anwendungen mit Microsoft Entra ID.

Authentifizierung

Die Anforderung ordnungsgemäßer Anmeldeinformationen von einer Partei. Bildet die Grundlage für die Erstellung eines Sicherheitsprinzipals für die Identitäts- und Zugriffssteuerung. Im Rahmen einer OAuth 2.0-Autorisierungsgewährung übernimmt die authentifizierende Partei beispielsweise abhängig von der verwendeten Gewährung entweder die Rolle des Ressourcenbesitzers oder die Rolle der Clientanwendung.

Authorization

Die Gewährung einer Handlungsberechtigung für einen authentifizierten Sicherheitsprinzipal. Im Programmiermodell von Microsoft Entra sind im Wesentlichen zwei Anwendungsfälle vorgesehen:

• Im Rahmen einer OAuth 2.0-Autorisierungsgewährung: Wenn der Ressourcenbesitzer die Clientanwendung autorisiert und dem Client dadurch Zugriff auf Ressourcen des Ressourcenbesitzers gewährt.
• Im Rahmen des Ressourcenzugriffs durch den Client: Gemäß Implementierung durch den Ressourcenserver unter Verwendung der Werte des Anspruchs aus dem Zugriffstoken, die als Grundlage für Zugriffssteuerungsentscheidungen herangezogen werden.

Authorization code (Autorisierungscode)

Ein kurzlebige Wert, der vom Autorisierungsendpunkt für eine Clientanwendung während des OAuth 2.0-Autorisierungscodeerteilungsflows bereitgestellt wird, einer der vier OAuth 2.0-Autorisierungserteilungen. Auch als Authentifizierungscode bezeichnet, wird der Autorisierungscode als Reaktion auf die Authentifizierung eines Ressourcenbesitzers an die Clientanwendung zurückgegeben. Der Authentifizierungscode gibt an, dass der Ressourcenbesitzer die Autorisierung an die Clientanwendung delegiert hat, um auf seine Ressourcen zuzugreifen. Im Rahmen des Ablaufs wird der Code gegen ein Zugriffstoken eingetauscht.

Authorization endpoint (Autorisierungsendpunkt)

Einer der vom Autorisierungsserver implementierten Endpunkte. Wird für die Interaktion mit dem Ressourcenbesitzer verwendet, um bei einem OAuth 2.0-Autorisierungsgewährungsablauf eine Autorisierungsgewährung bereitzustellen. Die tatsächliche Gewährung kann je nach verwendetem Autorisierungsgewährungsablauf variieren (einschließlich Autorisierungscode oder Sicherheitstoken).

Ausführlichere Informationen finden Sie in der OAuth 2.0-Spezifikation in den Abschnitten zu Autorisierungsgewährungstypen und zum Autorisierungsendpunkt sowie in der OpenIDConnect-Spezifikation.

Autorisierungsgewährung

Anmeldeinformationen, die die Autorisierung des Ressourcenbesitzers für den Zugriff auf seine geschützten Ressourcen durch eine Clientanwendung darstellen. Eine Clientanwendung kann abhängig von Clienttyp/Anforderungen einen der vier durch das OAuth 2.0-Autorisierungsframework definierten Gewährungstypen verwenden, um eine Gewährung zu beziehen. Zur Auswahl stehen Autorisierungscodegewährung, Clientanmeldeinformations-Gewährung, implizite Gewährung und Ressourcenbesitzerkennwort-Anmeldeinformationsgewährung. Bei den an den Client zurückgegebenen Anmeldeinformationen handelt es sich je nach Art des verwendeten Autorisierungsgewährungsablaufs entweder um ein Zugriffstoken oder um einen Autorisierungscode (der später gegen ein Zugriffstoken eingetauscht wird).

Die Kennwortanmeldeinformationen des Ressourcenbesitzers sollten nicht verwendet werden, außer in Szenarien, in dem andere Flows nicht verwendet werden können. Wenn Sie ein SPA erstellen, verwenden Sie den Autorisierungscodeflow mit PKCE anstelle der impliziten Erteilung.

Autorisierungsserver

Gemäß Definition des OAuth 2.0-Autorisierungsframeworks der Server für die Ausstellung von Zugriffstoken für den Client nach erfolgreicher Authentifizierung des Ressourcenbesitzers und Einholung seiner Autorisierung. Eine Clientanwendung interagiert mit dem Autorisierungsserver zur Laufzeit über dessen Autorisierungsendpunkte und Tokenendpunkte (in Einklang mit den durch OAuth 2.0 definierten Autorisierungsgewährungen).

Bei der Microsoft Identity Platform-Anwendungsintegration implementiert Microsoft Identity Platform die Autorisierungsserverrolle für Microsoft Entra-Anwendungen und Microsoft-Dienst-APIs, z. B. Microsoft Graph-APIs.

Anspruch

Ansprüche sind Namen-/Wertepaare in einem Sicherheitstoken, das Assertionen bereitstellt, die von einer Entität an eine andere vorgenommen werden. Diese Entitäten sind in der Regel die Clientanwendung oder ein Ressourcenbesitzer, der Assertionen an einen Ressourcenserver bereitstellt. Ansprüche übermitteln Fakten über den Antragsteller des Tokens, wie z. B. die ID des Sicherheitsprinzipals, der durch den Autorisierungsserver authentifiziert wurde. Die in einem Token vorhandenen Ansprüche können variieren und von mehreren Faktoren wie dem Tokentyp, dem Typ der Anmeldeinformationen, die für die Authentifizierung des Antragstellers, die Anwendungskonfiguration und andere verwendet werden, abhängig sein.

Weitere Details finden Sie unter Microsoft Identity Platform – Tokenreferenz.

Clientanwendung

Wird auch als Akteur bezeichnet. Gemäß Definition des OAuth 2.0-Autorisierungsframeworks eine Anwendung, die im Auftrag des Ressourcenbesitzers geschützte Ressourcen anfordert. Sie erhält vom Ressourcenbesitzer Berechtigungen in Form von Geltungsbereichen. Der Begriff „Client“ impliziert keine bestimmte Hardwareimplementierung (also beispielsweise, ob die Anwendung auf einem Server, Desktopcomputer oder anderen Gerät ausgeführt wird).

Eine Clientanwendung fordert eine Autorisierung von einem Ressourcenbesitzer an, um an einer OAuth 2.0-Autorisierungsgewährung teilzunehmen, und greift ggf. im Auftrag des Ressourcenbesitzers auf APIs/Daten zu. Das OAuth 2.0-Autorisierungsframework definiert zwei Arten von Clients: „vertraulich“ und „öffentlich“ – abhängig davon, ob der Client die Vertraulichkeit seiner Anmeldeinformationen gewährleisten kann. Anwendungen können einen auf einem Webserver ausgeführten Webclient (vertraulich), einen auf einem Gerät installierten nativen Client (öffentlich) oder einen im Browser eines Geräts ausgeführten Benutzer-Agent-basierten Client (öffentlich) implementieren.

Zustimmung

Der Vorgang, bei dem ein Ressourcenbesitzer einer Clientanwendung durch spezifische Berechtigungen die Autorisierung für den Zugriff auf geschützte Ressourcen (im Auftrag des Ressourcenbesitzers) gewährt. Abhängig von den vom Client angeforderten Berechtigungen wird die Zustimmung eines Administrators oder Benutzers angefordert, um den Zugriff auf die entsprechenden Organisationsdaten oder individuellen Daten zuzulassen. In einem Szenario mit mehreren Mandanten wird der Dienstprinzipal der Anwendung auch im Mandanten des zustimmenden Benutzers erfasst.

Weitere Informationen finden Sie unter Consent Framework.

ID-Token

Ein vom Autorisierungsendpunkt eines Autorisierungsservers bereitgestelltes OpenID Connect-Sicherheitstoken mit Ansprüchen in Verbindung mit der Authentifizierung eines Endbenutzers vom Typ Ressourcenbesitzer. ID-Token werden genau wie Zugriffstoken als digital signiertes JSON Web Token (JWT) dargestellt. Im Gegensatz zu einem Zugriffstoken werden die Ansprüche eines ID-Tokens allerdings nicht im Zusammenhang mit dem Zugriff auf Ressourcen und speziell mit der Zugriffssteuerung verwendet.

Weitere Informationen finden Sie in der ID-Tokenreferenz.

Verwaltete Identitäten

Entwickler müssen keine Anmeldeinformationen mehr verwalten. Verwaltete Identitäten stellen eine Identität bereit, mit deren Hilfe Anwendungen eine Verbindung mit Ressourcen herstellen können, welche die Microsoft Entra-Authentifizierung unterstützen. Anwendungen können die verwaltete Identität verwenden, um Microsoft Entra-Token abzurufen. Beispielsweise kann eine Anwendung eine verwaltete Identität verwenden, um auf Ressourcen wie Azure Key Vault zuzugreifen, in denen Entwickler Anmeldeinformationen auf sichere Weise speichern, oder um auf Speicherkonten zuzugreifen. Weitere Informationen finden Sie unter Übersicht über verwaltete Identitäten.

Microsoft Identity Platform

Die Microsoft Identity Platform ist eine Weiterentwicklung des Microsoft Entra-Identitätsdiensts und der zugehörigen Entwicklerplattform. Sie ermöglicht Entwicklern das Erstellen von Anwendungen, mit denen alle Microsoft-Identitäten angemeldet werden, und das Abrufen von Token zum Aufrufen von Microsoft Graph, anderen Microsoft-APIs oder von Entwicklern erstellten APIs. Es handelt sich um eine Plattform mit vollem Funktionsumfang, die einen Authentifizierungsdienst, Bibliotheken, Anwendungsregistrierung und -konfiguration, eine vollständige Entwicklerdokumentation, Codebeispiele und andere Inhalte für Entwickler umfasst. Microsoft Identity Platform unterstützt die branchenüblichen Protokolle, z.B. OAuth 2.0 und OpenID Connect.

Mehrinstanzenfähige Anwendung

Eine Anwendung, die Anmeldung und Zustimmung von Benutzern in beliebigen Microsoft Entra-Mandanten ermöglicht, auch auf anderen Mandanten als dem, auf dem der Client registriert ist. Native Clientanwendungen sind standardmäßig mehrinstanzenfähig. Bei Webclientanwendungen und Webressourcen-/API-Anwendungen kann es sich um Anwendungen mit einem einzelnen Mandanten oder um mehrinstanzenfähige Anwendungen handeln. Im Gegensatz dazu ermöglicht eine als einzelner Mandant registrierte Webanwendung nur Anmeldungen über Benutzerkonten, die unter dem gleichen Mandanten bereitgestellt wurden, bei dem auch die Anwendung registriert ist.

Ausführlichere Informationen finden Sie unter Anmelden von Microsoft Entra-Benutzern mit dem mehrinstanzenfähigen Anwendungsmuster.

Nativer Client

Eine Art von Clientanwendung , die nativ auf einem Gerät installiert ist. Da der gesamte Code auf einem Gerät ausgeführt wird und keine private/vertrauliche Speicherung von Anmeldeinformationen möglich ist, wird dieser Client als „öffentlich“ betrachtet. Ausführlichere Informationen finden Sie in den OAuth 2.0-Clienttypen und -profilen.

Berechtigungen

Eine Clientanwendung erhält Zugriff auf einen Ressourcenserver, indem sie Berechtigungsanforderungen deklariert. Zwei Arten sind verfügbar:

• Delegierte Berechtigungen: Geben bereichsbasierten Zugriff mit der delegierten Autorisierung des angemeldeten Ressourcenbesitzers an und werden der Ressource zur Laufzeit als SCP-Ansprüche im Zugriffstoken des Clients präsentiert. Diese geben die Berechtigung an, die dem Akteur vom Antragsteller erteilt werden.
• Anwendungsberechtigungen: Geben rollenbasierten Zugriff mit den Anmeldeinformationen und der Identität der Anwendung an und werden der Ressource zur Laufzeit als Rollenansprüche im Zugriffstoken des Clients präsentiert. Diese geben die Berechtigung an, die dem Antragsteller vom Mandanten erteilt werden.

Darüber hinaus werden sie im Rahmen des Zustimmungsprozesses verwendet, um dem Administrator oder Ressourcenbesitzer die Möglichkeit zu geben, den Clientzugriff auf Ressourcen in seinem Mandanten zu gewähren oder zu verweigern.

Berechtigungsanforderungen für eine Anwendung werden auf der Seite API-Berechtigungen konfiguriert. Dort wählen Sie die gewünschten delegierten Berechtigungen sowie die gewünschten Anwendungsberechtigungen aus (für Letzteres ist die Rolle „Globaler Administrator“ erforderlich). Da ein öffentlicher Client die Anmeldeinformationen nicht sicher verwalten kann, kann er nur delegierte Berechtigungen anfordern. Ein vertraulicher Client kann dagegen sowohl delegierte Berechtigungen als auch Anwendungsberechtigungen anfordern. Das Anwendungsobjekt des Clients speichert die deklarierten Berechtigungen in der requiredResourceAccess-Eigenschaft.

Aktualisierungstoken

Ein Sicherheitstokentyp, der von einem Autorisierungsserver ausgestellt wurde. Bevor ein Zugriffstoken abläuft, enthält eine Clientanwendung das zugehörige Aktualisierungstoken, wenn es ein neues Zugriffstoken vom Autorisierungsserver anfordert. Aktualisierungstoken werden in der Regel als JSON-Webtoken (JWT) formatiert.

Im Gegensatz zu Zugriffstoken können Aktualisierungstoken widerrufen werden. Ein Autorisierungsserver verweigert alle Anforderungen einer Clientanwendung, die ein Aktualisierungstoken enthält, das widerrufen wurde. Wenn der Autorisierungsserver eine Anforderung verweigert, die ein widerrufenes Aktualisierungstoken enthält, verliert die Clientanwendung die Berechtigung für den Zugriff auf den Ressourcenserver im Namen des Ressourcenbesitzers.

Weitere Informationen finden Sie unter Aktualisierungstoken.

Ressourcenbesitzer

Gemäß Definition des OAuth 2.0-Autorisierungsframeworks eine Entität, die Zugriff auf eine geschützte Ressource gewähren kann. Handelt es sich bei dem Ressourcenbesitzer um eine Person, wird er als Endbenutzer bezeichnet. Wenn also beispielsweise eine Clientanwendung über die Microsoft Graph-API auf das Postfach eines Benutzers zugreifen möchte, benötigt sie die Berechtigung des Ressourcenbesitzers für das Postfach. Der Ressourcenbesitzer wird manchmal auch als Antragsteller bezeichnet.

Jedes Sicherheitstoken stellt einen Ressourcenbesitzer dar. Der Ressourcenbesitzer wird durch den Antragstelleranspruch, den Objekt-ID-Anspruch und die personenbezogenen Daten im Token dargestellt. Ressourcenbesitzer sind die Partei, die einer Clientanwendung delegierte Berechtigungen in Form von Geltungsbereichen gewährt. Ressourcenbesitzer sind auch die Empfänger von Rollen, die erweiterte Berechtigungen innerhalb eines Mandanten oder für eine Anwendung angeben.

Ressourcenserver

Gemäß Definition des OAuth 2.0-Autorisierungsframeworks ein Server, der geschützte Ressourcen hostet und von Clientanwendungen, die ein Zugriffstoken vorlegen, Anforderungen für geschützte Ressourcen akzeptieren und darauf reagieren kann. Wird auch als geschützter Ressourcenserver oder als Ressourcenanwendung bezeichnet.

Ein Ressourcenserver macht APIs verfügbar und steuert den Zugriff auf seine geschützten Ressourcen über Bereiche und Rollen (unter Verwendung des OAuth 2.0-Autorisierungsframeworks). Beispiele wären etwa die Microsoft Graph-API (bietet Zugriff auf Azure AD-Mandantendaten) und die Microsoft 365-APIs (bieten Zugriff auf Daten wie E-Mails und Kalender).

Genau wie bei einer Clientanwendung wird auch die Identitätskonfiguration einer Ressourcenanwendung mittels Registrierung bei einem Azure AD-Mandanten eingerichtet und sowohl ein Anwendungs- als auch ein Dienstprinzipalobjekt bereitgestellt. Einige von Microsoft bereitgestellte APIs (etwa die Microsoft Graph-API) verfügen über vorab registrierte Dienstprinzipale, die bei der Bereitstellung in allen Mandanten verfügbar gemacht wurden.

Rollen

Mithilfe von App-Rollen kann ein Ressourcenserver ähnlich wie mit Bereichen den Zugriff auf seine geschützten Ressourcen steuern. Im Gegensatz zu Bereichen stellen Rollen Berechtigungen dar, die dem Antragsteller über die Baseline hinaus gewährt wurden. Aus diesem Grund ist das Lesen Ihrer eigenen E-Mails ein Bereich, ein E-Mail-Administrator, der die E-Mails aller Benutzer lesen kann, ist jedoch eine Rolle.

App-Rollen können zwei Zuweisungstypen unterstützen: Eine Benutzerzuweisung implementiert eine rollenbasierte Zugriffssteuerung für Benutzer/Gruppen, die Zugriff auf die Ressource benötigen. Eine Anwendungszuweisung implementiert das Gleiche für Clientanwendungen, die Zugriff benötigen. Eine App-Rolle kann als zuweisbar für Benutzer, zuweisbar für Apps oder beides definiert werden.

Bei Rollen handelt es sich um ressourcendefinierte Zeichenfolgen (wie etwa „Ausgabengenehmiger“, „Schreibgeschützt“, „Directory.ReadWrite.All“). Sie werden über das Anwendungsmanifest der Ressource verwaltet und in der appRoles-Eigenschaft der Ressource gespeichert. Benutzer*innen können Benutzerrollen zugewiesen werden, und Clientanwendungsberechtigungen können konfiguriert werden, um zuweisbare Anwendungsrollen anzufordern.

Ausführliche Informationen zu den Anwendungsrollen, die von der Microsoft Graph-API verfügbar gemacht werden, finden Sie unter Graph-API-Berechtigungsbereiche. Ein ausführliches Implementierungsbeispiel finden Sie unter Hinzufügen oder Entfernen von Azure-Rollenzuweisungen.

Bereiche

Mithilfe von Bereichen kann ein Ressourcenserver ähnlich wie mit Rollen den Zugriff auf seine geschützten Ressourcen steuern. Bereiche dienen zum Implementieren einer bereichsbasierten Zugriffssteuerung für eine Clientanwendung, der durch den Ressourcenbesitzer delegierter Zugriff auf die Ressource gewährt wurde.

Bei Bereichen handelt es sich um ressourcendefinierte Zeichenfolgen (wie etwa „Mail.Read“, „Directory.ReadWrite.All“). Sie werden über das Anwendungsmanifest der Ressource verwaltet und in der oauth2Permissions-Eigenschaft der Ressource gespeichert. Delegierte Berechtigungen für Clientanwendungen können für den Zugriff auf einen Bereich konfiguriert werden.

Als Benennungskonvention hat sich das Format „Ressource.Vorgang.Einschränkung“ bewährt. Ausführliche Informationen zu den Bereichen, die von der Microsoft Graph-API verfügbar gemacht werden, finden Sie unter Graph-API-Berechtigungsbereiche. Informationen zu von Microsoft 365-Diensten verfügbar gemachten Bereichen finden Sie unter Referenz für Microsoft 365-API-Berechtigungen.

Sicherheitstoken

Ein signiertes Dokument mit Ansprüchen (etwa ein OAuth 2.0-Token oder eine SAML 2.0-Assertion). Bei einer OAuth 2.0-Autorisierungsgewährung zählen Zugriffstoken (OAuth2), Aktualisierungstoken und ID-Token zu den Sicherheitstoken, die alle als JSON Web Token (JWT) implementiert werden.

Dienstprinzipalobjekt

Wenn Sie eine Anwendung registrieren bzw. aktualisieren, werden sowohl ein Anwendungsobjekt als auch ein entsprechendes Dienstprinzipalobjekt für den Mandanten erstellt bzw. aktualisiert. Das Anwendungsobjekt definiert die Identitätskonfiguration der Anwendung global (also für alle Mandanten, für die der zugeordneten Anwendung Zugriff gewährt wurde) und fungiert als Vorlage, von der die entsprechenden Dienstprinzipalobjekte für die lokale Verwendung zur Laufzeit (in einem bestimmten Mandanten) abgeleitet werden.

Weitere Informationen finden Sie unter Anwendungsobjekte und Dienstprinzipalobjekte.

Anmeldung

Die Initiierung einer Endbenutzerauthentifizierung durch eine Clientanwendung sowie die Erfassung des entsprechenden Zustands, um ein Sicherheitstoken zu beziehen und die Anwendungssitzung auf den Zustand abzustimmen. Der Zustand kann Artefakte wie Benutzerprofilinformationen und aus Tokenansprüchen abgeleitete Informationen enthalten.

Die Anmeldefunktion wird in der Regel zum Implementieren von Single-Sign-on (SSO) verwendet. Ihr kann auch eine Registrierungsfunktion vorangestellt werden, die als Einstiegspunkt für einen Endbenutzer dient, um ihm (bei der ersten Anmeldung) Zugriff auf eine Anwendung zu gewähren. Die Registrierungsfunktion dient zum Sammeln und Beibehalten eines zusätzlichen, benutzerspezifischen Zustands und erfordert unter Umständen die Zustimmung des Benutzers.

Abmeldung

Die Aufhebung der Authentifizierung eines Benutzers, wobei der Benutzerzustand, der der Sitzung der Clientanwendung bei der Anmeldung zugeordnet wurde, getrennt wird.

Subject

Wird auch als Ressourcenbesitzer bezeichnet.

Tenant

Eine Instanz eines Microsoft Entra-Verzeichnisses wird als Microsoft Entra-Mandant bezeichnet. Sie bietet verschiedene Funktionen einschließlich:

• einen Registrierungsdienst für integrierte Anwendungen
• Authentifizierung von Benutzerkonten und registrierten Anwendungen
• REST-Endpunkte, die zur Unterstützung verschiedener Protokolle (einschließlich OAuth2.0 und SAML) erforderlich sind, z. B. der Autorisierungsendpunkt, der Tokenendpunkt und der allgemeine, von mehrinstanzenfähigen Anwendungen verwendete Endpunkt.

Microsoft Entra-Mandanten werden mit Azure- und Microsoft 365-Abonnements bei der Registrierung erstellt/zugewiesen und stellen Identity & Access Management-Features für das Abonnement bereit. Azure-Abonnementadministrator*innen können auch zusätzliche Microsoft Entra-Mandanten erstellen. Ausführliche Informationen zu den verschiedenen Möglichkeiten für den Zugriff auf einen Mandanten finden Sie unter Einrichten eines Microsoft Entra-Mandanten. Einzelheiten zur Beziehung zwischen Abonnements und einem Microsoft Entra-Mandanten sowie Anweisungen zum Zuordnen oder Hinzufügen eines Abonnements zu einem Microsoft Entra-Mandanten finden Sie unter Zuordnen oder Hinzufügen eines Azure-Abonnements zu Ihrem Microsoft Entra-Mandanten.

Token endpoint (Tokenendpunkt)

Einer der vom Autorisierungsserver implementierten Endpunkte zur Unterstützung von OAuth 2.0-Autorisierungsgewährungen. Kann je nach verwendeter Gewährung zum Abrufen eines Zugriffstokens (und eines zugehörigen „Aktualisierungstokens“) für einen Client oder eines ID-Tokens verwendet werden, wenn die Gewährung in Kombination mit dem OpenID Connect-Protokoll verwendet wird.

Benutzer-Agent-basierter Client

Ein Typ von Clientanwendung, der Code von einem Webserver herunterlädt und innerhalb eines Benutzer-Agents (z.B. in einem Webbrowser) ausgeführt wird. Ein Beispiel wäre eine Single-Page-Webanwendung (SPA). Da der gesamte Code auf einem Gerät ausgeführt wird und keine private/vertrauliche Speicherung von Anmeldeinformationen möglich ist, wird dieser Client als „öffentlich“ betrachtet. Ausführlichere Informationen finden Sie in den OAuth 2.0-Clienttypen und -profilen.

Benutzerprinzipal

Ein Benutzerprinzipalobjekt ist (ähnlich wie ein Dienstprinzipalobjekt, das eine Anwendungsinstanz darstellt) eine weitere Art von Sicherheitsprinzipal und stellt einen Benutzer dar. Der UserRessourcentyp Microsoft Graph definiert das Schema für ein Benutzerobjekt, einschließlich benutzerbezogener Eigenschaften wie Vor- und Nachname, Benutzerprinzipalname, Verzeichnisrollenzugehörigkeit usw. Dies stellt die Benutzeridentitätskonfiguration für Microsoft Entra ID bereit, um einen Benutzerprinzipal zur Laufzeit einzurichten. Der Benutzerprinzipal stellt bei der Erfassung der Delegierung der Zustimmung sowie bei Zugriffssteuerungsentscheidungen und Ähnlichem einen authentifizierten Benutzer für das einmalige Anmelden dar.

Webclient

Eine Art von Clientanwendung, die sämtlichen Code auf einem Webserver ausführt und als vertraulicher Client fungiert, weil er Anmeldeinformationen sicher auf dem Server speichern kann. Ausführlichere Informationen finden Sie in den OAuth 2.0-Clienttypen und -profilen.

Workload-Identität

Identität, die von einer Softwareworkload wie einer Anwendung, einem Dienst, Skript oder Container für die Authentifizierung und den Zugriff auf andere Dienste und Ressourcen verwendet wird. In Microsoft Entra ID zählen Apps, Dienstprinzipale und verwaltete Identitäten zu den Workload-Identitäten. Weitere Informationen finden Sie in der Übersicht über Workload-Identitäten.

Workload-Identitätsverbund

Ermöglicht den sicheren Zugriff auf durch Microsoft Entra geschützte Ressourcen von externen Apps und Diensten, ohne Geheimnisse verwalten zu müssen (bei unterstützten Szenarien). Weitere Informationen finden Sie unter Workload-Identitätsverbund.

Nächste Schritte

Viele der Begriffe in diesem Glossar beziehen sich auf die OAuth 2.0- und OpenID Connect-Protokolle. Obwohl Sie nicht wissen müssen, wie die Protokolle im Detail funktionieren, um die Identitätsplattform zu verwenden, kann es Ihnen helfen, die Authentifizierung und Autorisierung in Ihren Apps einfacher zu erstellen und zu debuggen, wenn Sie einige Protokollgrundsätze kennen:

• OAuth 2.0 und OpenID Connect (OIDC) auf der Microsoft Identity Platform