Teilen über

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

  • Artikel

Kenntnisse über OAuth oder OpenID Connect (OIDC) auf Protokollebene sind für die Nutzung der Microsoft Identity Platform nicht erforderlich. Sie werden jedoch mit Protokollbegriffen und Konzepten konfrontiert, wenn Sie die Identitätsplattform verwenden, um Ihren Apps Authentifizierung hinzuzufügen. Wenn Sie mit dem Microsoft Entra Admin Center, unserer Dokumentation und Authentifizierungsbibliotheken arbeiten, kann die Kenntnis einiger Grundlagen die Integration erleichtern und das Erlebnis insgesamt verbessern.

Rollen in OAuth 2.0

Vier Parteien sind im Allgemeinen an einem OAuth 2.0- und OpenID Connect-Authentifizierungs- und Autorisierungsaustausch beteiligt. Solche Austauschvorgänge werden häufig als Authentifizierungsflows oder Auth-Flows bezeichnet.

Diagramm mit OAuth 2.0-Rollen

  • Autorisierungsserver: Die Microsoft Identity Platform ist der Autorisierungsserver. Er wird auch als Identitätsanbieter oder IdP bezeichnet und verarbeitet die Informationen des Endbenutzers, seinen Zugriff und die Vertrauensstellungs-Beziehungen zwischen den Parteien im Auth-Flow sicher. Der Autorisierungsserver stellt die Sicherheitstoken aus, die Ihre Apps und APIs zum Gewähren, Verweigern oder Widerrufen des Zugriffs auf Ressourcen (Autorisierung) verwenden, nachdem sich der Benutzer angemeldet (authentifiziert) hat.

  • Client: Der Client in einem OAuth-Austausch ist die Anwendung, die Zugriff auf eine geschützte Ressource anfordert. Der Client kann eine Web-App sein, die auf einem Server ausgeführt wird, eine Single-Page-Web-App, die im Webbrowser eines Benutzers ausgeführt wird, oder eine Web-API, die eine andere Web-API aufruft. Häufig wird der Client als Clientanwendung, Anwendung oder App bezeichnet.

  • Ressourcenbesitzer – Der Ressourcenbesitzer in einem Authentifizierungsflow ist normalerweise der Anwendungsbenutzer, oder Endbenutzer, in der OAuth-Terminologie. Der Endbenutzer „besitzt“ die geschützte Ressource (seine Daten), auf die Ihre App in seinem Namen zugreift. Die Ressourcenbesitzerinnen und -besitzer können Ihrer App (dem Client) Zugriff auf die eigenen Ressourcen gewähren oder verweigern. Beispielsweise könnte Ihre App die API eines externen Systems aufrufen, um die E-Mail-Adresse eines Benutzers aus dessen Profil auf diesem System abzurufen. Die Profildaten sind eine Ressource, die der Endbenutzer im externen System besitzt, und der Endbenutzer kann der Anforderung Ihrer App, auf ihre Daten zuzugreifen, zustimmen oder diese verweigern.

  • Ressourcenserver: Der Ressourcenserver hostet oder gewährt Zugriff auf die Daten eines Ressourcenbesitzers. In den meisten Fällen ist der Ressourcenserver eine Web-API, die einem Datenspeicher vorliegt. Der Ressourcenserver nutzt den Autorisierungsserver für die Authentifizierung und verwendet Informationen in Bearertoken, die vom Autorisierungsserver ausgestellt wurden, um den Zugriff auf Ressourcen zu gewähren oder zu verweigern.

Token

Die Parteien in einem Authentifizierungsflow verwenden Bearertoken, um einen Prinzipal (Benutzer, Host oder Dienst) zu gewährleisten, zu überprüfen und zu authentifizieren und den Zugriff auf geschützte Ressourcen (Autorisierung) zu gewähren oder zu verweigern. Bearertoken werden in der Microsoft Identity Platform als JSON-Webtoken (JWT) formatiert.

Drei Arten von Bearertoken werden von der Microsoft-Identitätsplattform als Sicherheitstoken verwendet:

  • Zugriffstoken: Zugriffstoken werden vom Autorisierungsserver für die Clientanwendung ausgestellt. Der Client übergibt dem Ressourcenserver Zugriffstoken. Zugriffstoken enthalten die Berechtigungen, die dem Client vom Autorisierungsserver erteilt wurden.

  • ID-Token: ID-Token werden vom Autorisierungsserver für die Clientanwendung ausgestellt. Clients verwenden ID-Token, wenn sie Benutzer anmelden und um grundlegende Informationen über sie zu erhalten.

  • Aktualisierungstoken: Der Client verwendet ein Aktualisierungstoken (RT), um neue Zugriffs- und ID-Token vom Autorisierungsserver anzufordern. Ihr Code sollte Aktualisierungstoken und deren Zeichenfolgeninhalte als vertrauliche Daten behandeln, da sie nur für die Verwendung durch den Autorisierungsserver vorgesehen sind.

App-Registrierung

Ihre Client-App benötigt eine Möglichkeit, den Sicherheitstoken zu vertrauen, die ihr von der Microsoft Identity Platform ausgestellt wurden. Der erste Schritt beim Einrichten der Vertrauensstellung ist die Registrierung Ihrer App. Wenn Sie Ihre App registrieren, weist die Identitätsplattform ihr automatisch einige Werte zu, während andere Werte von Ihnen basierend auf dem Typ der Anwendung konfiguriert werden.

Es folgen zwei der am häufigsten verwendeten App-Registrierungseinstellungen:

  • Anwendungs-ID (Client-ID) – Dieser Wert, auch als Anwendungs-ID und Client-ID bezeichnet, wird Ihrer App durch die Identitätsplattform zugewiesen. Die Client-ID identifiziert Ihre App eindeutig auf der Identity Platform und ist in den Sicherheitstoken enthalten, die die Plattform ausgibt.
  • Umleitungs-URI: Der Autorisierungsserver verwendet eine Umleitungs-URI, um den Benutzer-Agent des Ressourcenbesitzers (Webbrowser, mobile App) nach Abschluss der Interaktion an ein anderes Ziel weiterzuleiten. Beispielsweise, nachdem sich der Endbenutzer beim Autorisierungsserver authentifiziert hat. Nicht alle Clienttypen verwenden Umleitungs-URIs.

Die Registrierung Ihrer App enthält auch Informationen zu den Authentifizierungs- und Autorisierungs-Endpunkten, die Sie in Ihrem Code zum Abrufen von ID- und Zugriffstoken verwenden.

Endpunkte

Die Microsoft Identity Platform bietet Authentifizierungs- und Autorisierungsdienste mit standardkonformen Implementierungen von OAuth 2.0 und OpenID Connect (OIDC) 1.0. Standardkonforme Autorisierungsserver wie die Identitätsplattform bieten eine Reihe von HTTP-Endpunkten, die von den Parteien in einem Authentifizierungsflow zum Ausführen des Flows verwendet werden können.

Die Endpunkt-URIs für Ihre App werden automatisch generiert, wenn Sie Ihre App registrieren oder konfigurieren. Welche Endpunkte Sie im Code Ihrer App verwenden, hängt vom Typ der Anwendung und den Identitäten (Kontotypen) ab, die sie unterstützen soll.

Zwei häufig verwendete Endpunkte sind der Autorisierungsendpunkt und der Tokenendpunkt. Hier finden Sie Beispiele für die authorize- und token-Endpunkte:

# Authorization endpoint - used by client to obtain authorization from the resource owner.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/authorize
# Token endpoint - used by client to exchange an authorization grant or refresh token for an access token.
https://login.microsoftonline.com/<issuer>/oauth2/v2.0/token

# NOTE: These are examples. Endpoint URI format may vary based on application type,
#       sign-in audience, and Azure cloud instance (global or national cloud).

#       The {issuer} value in the path of the request can be used to control who can sign into the application. 
#       The allowed values are **common** for both Microsoft accounts and work or school accounts, 
#       **organizations** for work or school accounts only, **consumers** for Microsoft accounts only, 
#       and **tenant identifiers** such as the tenant ID or domain name.

Um die Endpunkte für eine von Ihnen registrierte Anwendung zu finden, navigieren Sie im Microsoft Entra Admin Center zu:

Identität>Anwendungen>App- Registrierungen><YOUR-APPLICATION>>Entpunkte

Nächste Schritte

Als Nächstes erfahren Sie mehr über die OAuth 2.0-Authentifizierungsflows, die von den einzelnen Anwendungstypen verwendet werden, und die Bibliotheken, die Sie in Ihren Apps verwenden können, um sie auszuführen:

Wir raten dringend davon ab, ihre eigene Bibliothek oder unformatierte HTTP-Aufrufe zum Ausführen von Authentifizierungsflows zu erstellen. Eine Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) ist sicherer und einfacher. Wenn Ihr Szenario jedoch verhindert, dass Sie unsere Bibliotheken verwenden, oder wenn Sie einfach mehr über die Implementierung der Microsoft Identity Platform erfahren möchten, finden Sie hier eine Protokollreferenz: