OAuth 2.0 und OpenID Connect-Protokolle in Microsoft Identity Platform

Der Microsoft Identity Platform-Endpunkt für Identity-as-a-Service implementiert die Authentifizierung und Autorisierung mit den Industriestandardprotokollen OpenID Connect (OIDC) bzw. OAuth 2.0. Auch wenn der Dienst den Standard entspricht, kann es feine Unterschiede zwischen zwei Implementierungen dieser Protokolle geben. Die hier bereitgestellten Informationen sind hilfreich, wenn Sie Code direkt durch Senden und Verarbeiten von HTTP-Anforderungen schreiben oder eine Open-Source-Bibliothek eines Drittanbieters verwenden, statt eine unserer Open-Source-Bibliotheken zu nutzen.

Grundlagen

In fast allen OAuth 2.0- und OpenID Connect-Vorgängen sind vier Beteiligte am Austausch involviert:

Diagramm mit OAuth 2.0-Rollen

  • Microsoft Identity Platform ist der Autorisierungsserver und verantwortlich für das Sicherstellen der Identität des Benutzers, das Erteilen und Widerrufen des Zugriffs auf Ressourcen und das Ausstellen von Token. Der Autorisierungsserver ist auch als Identitätsanbieter bekannt und verarbeitet auf sichere Weise alles im Zusammenhang mit den Informationen des Benutzers, dessen Zugriff und den Vertrauensstellungen zwischen den Beteiligten in einem Vorgang.
  • Beim Ressourcenbesitzer handelt es sich normalerweise um den Endbenutzer. Diese Partei besitzt die Daten und hat die Möglichkeit, Clients den Zugriff auf die Daten oder die Ressource zu gewähren.
  • Der OAuth-Client ist Ihre App, die durch ihre Anwendungs-ID identifiziert wird. Der OAuth-Client ist normalerweise der Beteiligte, mit dem der Endbenutzer interagiert, und der Token vom Autorisierungsserver anfordert. Der Client muss vom Besitzer der Ressource die Berechtigung zum Zugriff darauf erhalten.
  • Der Ressourcenserver ist der Ort, an dem die Ressource oder die Daten abgelegt sind. Er vertraut dem Autorisierungsserver, dass der OAuth-Client sicher authentifiziert und autorisiert wird, und verwendet Bearerzugriffstoken, um sicherzustellen, dass der Zugriff auf eine Ressource gewährt werden kann.

App-Registrierung

Jede App, die sowohl persönliche als auch Geschäfts-, Schul- oder Unikonten akzeptieren soll, muss über die Funktion App-Registrierungen des Azure-Portals registriert werden, bevor diese Benutzer mit OAuth 2.0 oder OpenID Connect angemeldet werden können. Der Registrierungsprozess für die App sammelt einige Werte und weist ihr einige Werte zu:

  • Eine Anwendungs-ID, die Ihre App eindeutig identifiziert
  • Ein Umleitungs-URI (optional), der zum Umleiten von Antworten zurück an die App verwendet werden kann.
  • Einige andere szenariospezifische Werte.

Weitere Informationen finden Sie im Artikel zum Registrieren von Apps.

Endpunkte

Nach der Registrierung kommuniziert die App mit Microsoft Identity Platform, indem sie Anforderungen an den Endpunkt sendet:

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Dabei ist für {tenant} einer von vier verschiedenen Werten möglich:

Wert BESCHREIBUNG
common Ermöglicht Benutzern mit persönlichen Microsoft-Konten und Geschäfts-, Schul- oder Unikonten aus Azure AD die Anmeldung bei der Anwendung.
organizations Ermöglicht nur Benutzern mit Geschäfts-, Schul- oder Unikonten aus Azure AD die Anmeldung bei der Anwendung.
consumers Ermöglicht nur Benutzern mit persönlichen Microsoft-Konten (MSA) die Anmeldung bei der Anwendung.
8eaef023-2b34-4da1-9baa-8bc8c9d6a490 oder contoso.onmicrosoft.com Ermöglicht nur Benutzern mit Geschäfts-, Schul- oder Unikonten eines bestimmten Azure AD-Mandanten die Anmeldung bei der Anwendung. Dabei kann entweder der Anzeigename der Domäne des Azure AD-Mandanten oder der GUID-Bezeichner des Mandanten verwendet werden.

Um zu erfahren, wie Sie mit diesen Endpunkten interagieren, wählen Sie im Abschnitt Protokolle einen bestimmten App-Typ aus, und folgen Sie den Links für weitere Informationen.

Tipp

Jede in Azure AD registrierte App kann Microsoft Identity Platform verwenden, selbst wenn keine persönlichen Konten angemeldet werden. Auf diese Weise können Sie vorhandene Anwendungen zu Microsoft Identity Platform und MSAL migrieren, ohne Ihre Anwendung neu erstellen zu müssen.

Token

OAuth 2.0 und OpenID Connect machen umfassende Verwendung von Bearertoken, die in der Regel als JSON Web Token (JWT) bereitgestellt werden. Ein Bearertoken ist ein einfaches Sicherheitstoken, das dem „Bearer“ (Träger) den Zugriff auf eine geschützte Ressource ermöglicht. In diesem Sinn ist der „Bearer“ jeder, der eine Kopie des Tokens erhält. Um das Bearertoken zu erhalten, muss sich die Partei zwar zunächst bei Microsoft Identity Platform authentifizieren, falls jedoch keine Maßnahmen ergriffen werden, um das Token bei der Übertragung und Speicherung zu schützen, kann das Token von einer fremden Partei abgefangen und verwendet werden. Einige Sicherheitstoken verfügen über einen integrierten Mechanismus, der eine unbefugte Verwendung durch nicht autorisierte Parteien verhindert. Trägertoken besitzen dagegen keinen solchen Mechanismus und müssen über einen sicheren Kanal wie etwa Transport Layer Security (HTTPS) übertragen werden. Wird ein Bearertoken als Klartext gesendet, kann eine böswillige Partei das Token mithilfe eines Man-in-the-Middle-Angriffs abfangen und damit unautorisiert auf eine geschützte Ressource zugreifen. Die gleichen Sicherheitsprinzipien gelten für die (Zwischen-)Speicherung von Trägertoken zur späteren Verwendung. Stellen Sie daher sicher, dass Ihre App Bearertoken stets auf sichere Weise überträgt und speichert. Weitere Sicherheitsüberlegungen zu Bearertoken finden Sie unter RFC 6750, Abschnitt 5.

Bei OAuth 2.0 und OIDC werden in erster Linie drei Typen von Token verwendet:

  • Zugriffstoken sind Token, die ein Ressourcenserver von einem Client empfängt und die die Berechtigungen enthalten, die dem Client erteilt wurden.
  • ID-Token sind Token, die von einem Client vom Autorisierungsserver empfangen und zum Anmelden eines Benutzers sowie zum Abrufen grundlegender Informationen zu diesem verwendet werden.
  • Aktualisierungstoken werden von einem Client verwendet, um im Lauf der Zeit neue Zugriffs- und ID-Token abzurufen. Dabei handelt es sich um nicht transparente Zeichenfolgen, die nur vom Autorisierungsserver verstanden werden können.

Protokolle

Wenn Sie einige Beispielanforderungen sehen möchten, beginnen Sie mit einem der folgenden Protokolldokumente. Jedes Lernprogramm entspricht einem bestimmten Szenario. Wenn Sie Hilfe bei der Bestimmung des richtigen Flows benötigen, informieren Sie sich über die App-Typen, die mit Microsoft Identity Platform erstellt werden können.