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

Sie müssen OAuth oder OpenID Connect (OIDC) nicht auf Protokollebene erlernen, um die Microsoft Identity Platform verwenden zu können. Sie werden jedoch auf diese und andere Protokollbegriffe und -konzepte stoßen, wenn Sie die Identitätsplattform verwenden, um Ihren Apps Authentifizierungsfunktionen hinzuzufügen.

Wenn Sie mit dem Azure-Portal, unserer Dokumentation und unseren Authentifizierungsbibliotheken arbeiten, können Ihnen ein paar Grundkenntnisse wie diese Ihre Integrations- und Debugaufgaben erleichtern.

Rollen in OAuth 2.0

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

Diagram showing the OAuth 2.0 roles

  • Autorisierungsserver: Die Microsoft Identity Platform selbst 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 in der Regel der Anwendungsbenutzer oder der Endbenutzer in der OAuth-Terminologie. Der Endbenutzer „besitzt“ die geschützte Ressource – seine Daten –, auf die Ihre App in seinem Namen zugreift. Der Ressourcenbesitzer kann Ihrer App (dem Client) Zugriff auf die Ressourcen, die er besitzt, 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 Identity Platform 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 Zeichenfolgeninhalt als opak 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 dieser Vertrauensstellung besteht darin, Ihre App bei der Identity Platform in Azure Active Directory (Azure AD) zu registrieren.

Wenn Sie Ihre App in Azure AD registrieren, weist die Microsoft Identity Platform ihr automatisch einige Werte zu, während andere Werte von Ihnen, basierend auf dem Typ der Anwendung, konfiguriert werden.

Zwei der am häufigsten verwendeten App-Registrierungseinstellungen sind:

  • Anwendungs-ID (Client-ID): Dieser Wert wird auch als Anwendungs-ID und Client-ID bezeichnet und von der Microsoft Identity Platform Ihrer App 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 Microsoft Identity Platform bieten eine Reihe von HTTP-Endpunkten, die von den Parteien in einem Auth-Flow zum Ausführen des Flows verwendet werden können.

Die Endpunkt-URIs für Ihre App werden für Sie generiert, wenn Sie Ihre App in Azure AD 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 Anwendung zu finden, die Sie registriert haben, gehen Sie im Azure-Portal zu:

Azure Active Directory>App-Registrierungen><IHRE-ANWENDUNG>>Endpunkte

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 ist sicherer und viel einfacher. Wenn Ihr Szenario jedoch verhindert, dass Sie unsere Bibliotheken verwenden, oder Sie einfach mehr über die Implementierung der Identitätsplattform erfahren möchten, finden Sie hier eine Protokollreferenz: