Freigeben über

Übersicht über Token in Azure Active Directory B2C

Von Bedeutung

Ab dem 1. Mai 2025 steht Azure AD B2C nicht mehr für neue Kunden zur Verfügung. Weitere Informationen finden Sie in unseren HÄUFIG gestellten Fragen.

Azure Active Directory B2C (Azure AD B2C) gibt unterschiedliche Arten von Sicherheitstoken aus, während jeder Authentifizierungsfluss verarbeitet wird. In diesem Artikel werden das Format, die Sicherheitsmerkmale und der Inhalt jedes Tokentyps beschrieben.

Tokentypen

Azure AD B2C unterstützt die OAuth 2.0- und OpenID Connect-Protokolle, die Token für die Authentifizierung und den sicheren Zugriff auf Ressourcen verwenden. Alle in Azure AD B2C verwendeten Token sind JSON-Webtoken (JWTs), die Assertionen von Informationen über den Bearer und den Betreff des Tokens enthalten.

Die folgenden Token werden in der Kommunikation mit Azure AD B2C verwendet:

  • ID-Token – Ein JWT, das Ansprüche enthält, die Sie verwenden können, um Benutzer in Ihrer Anwendung zu identifizieren. Dieses Token wird sicher in HTTP-Anforderungen für die Kommunikation zwischen zwei Komponenten derselben Anwendung oder desselben Diensts gesendet. Sie können die Ansprüche nach Bedarf in einem ID-Token verwenden. Sie werden häufig verwendet, um Kontoinformationen anzuzeigen oder Zugriffssteuerungsentscheidungen in einer Anwendung zu treffen. Die von Azure AD B2C ausgestellten ID-Token sind signiert, aber nicht verschlüsselt. Wenn Ihre Anwendung oder API ein ID-Token empfängt, muss sie die Signatur überprüfen, um zu beweisen, dass das Token authentifiziert ist. Ihre Anwendung oder API muss auch einige Ansprüche im Token überprüfen, um zu beweisen, dass sie gültig ist. Abhängig von den Szenarioanforderungen können die von einer Anwendung überprüften Ansprüche variieren, ihre Anwendung muss jedoch einige allgemeine Anspruchsüberprüfungen in jedem Szenario ausführen.

  • Zugriffstoken – Ein JWT, das Ansprüche enthält, die Sie verwenden können, um die erteilten Berechtigungen für Ihre APIs zu identifizieren. Zugriffstoken sind signiert, aber sie werden nicht verschlüsselt. Zugriffstoken werden verwendet, um Zugriff auf APIs und Ressourcenserver bereitzustellen. Wenn Ihre API ein Zugriffstoken empfängt, muss sie die Signatur überprüfen, um zu bestätigen, dass das Token authentifiziert ist. Ihre API muss auch einige Ansprüche im Token überprüfen, um zu beweisen, dass sie gültig ist. Abhängig von den Szenarioanforderungen können die von einer Anwendung überprüften Ansprüche variieren, ihre Anwendung muss jedoch einige allgemeine Anspruchsüberprüfungen in jedem Szenario ausführen.

  • Aktualisierungstoken – Aktualisierungstoken werden verwendet, um neue ID-Token und Zugriffstoken in einem OAuth 2.0-Fluss abzurufen. Sie bieten Ihrer Anwendung langfristigen Zugriff auf Ressourcen im Namen der Benutzer, ohne dass eine Interaktion mit diesen Benutzern erforderlich ist. Aktualisierungstoken sind für Ihre Anwendung nicht transparent. Sie werden von Azure AD B2C ausgestellt und können nur von Azure AD B2C überprüft und interpretiert werden. Sie sind langanhaltend, aber Ihre Anwendung sollte nicht mit der Erwartung geschrieben werden, dass ein Aktualisierungs-Token für einen bestimmten Zeitraum gültig ist. Aktualisierungstoken können aus verschiedenen Gründen jederzeit ungültig werden. Die einzige Möglichkeit für Ihre Anwendung zu wissen, ob ein Aktualisierungstoken gültig ist, besteht darin, es einzulösen, indem sie eine Tokenanforderung an Azure AD B2C senden. Wenn Sie ein Aktualisierungstoken für ein neues Token einlösen, erhalten Sie ein neues Aktualisierungstoken in der Tokenantwort. Speichern Sie das neue Aktualisierungstoken. Es ersetzt das Aktualisierungstoken, das Sie zuvor in der Anforderung verwendet haben. Diese Aktion trägt dazu bei, sicherzustellen, dass Ihre Aktualisierungstoken so lange wie möglich gültig bleiben. Einzelseitenanwendungen, die den Autorisierungscodefluss mit PKCE verwenden, haben immer eine Aktualisierungstokenlebensdauer von 24 Stunden. Erfahren Sie mehr über die Sicherheitsauswirkungen von Aktualisierungstoken im Browser.

Endpunkte

Eine registrierte Anwendung empfängt Token und kommuniziert mit Azure AD B2C, indem Anforderungen an diese Endpunkte gesendet werden:

  • https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
  • https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Sicherheitstoken, die Ihre Anwendung von Azure AD B2C empfängt, können von den /authorize oder /token Endpunkten stammen. Wenn ID-Token aus den folgenden Quellen erworben werden:

  • /authorize Endpunkt, dies geschieht mit dem implicit flow, der häufig verwendet wird, damit Benutzer sich bei JavaScript-basierten Webanwendungen anmelden. Wenn Ihre App jedoch MSAL.js 2.0 oder höher verwendet, aktivieren Sie die implizite Flusserteilung in Ihrer App-Registrierung nicht, da MSAL.js 2.0+ den Autorisierungscodefluss mit PKCE unterstützt.
  • /token-Endpunkt: Hierfür wird der Autorisierungscodefluss genutzt, bei dem das Token dem Browser verborgen bleibt.

Ansprüche

Wenn Sie Azure AD B2C verwenden, haben Sie eine differenzierte Kontrolle über den Inhalt Ihrer Token. Sie können Benutzerflüsse und benutzerdefinierte Richtlinien so konfigurieren, dass bestimmte Benutzerdatensätze in Ansprüchen gesendet werden, die für Ihre Anwendung erforderlich sind. Diese Ansprüche können Standardeigenschaften wie displayName und emailAddress enthalten. Ihre Anwendungen können diese Ansprüche verwenden, um Benutzer und Anforderungen sicher zu authentifizieren.

Die Ansprüche in ID-Token werden in keiner bestimmten Reihenfolge zurückgegeben. Neue Ansprüche können jederzeit in ID-Token eingeführt werden. Ihre Anwendung darf durch die Einführung neuer Ansprüche nicht beschädigt werden. Sie können auch benutzerdefinierte Benutzerattribute in Ihre Ansprüche einschließen.

In der folgenden Tabelle sind die Ansprüche aufgeführt, die Sie in ID-Token und Zugriffstoken erwarten können, die von Azure AD B2C ausgestellt wurden.

Name Anspruch Beispielwert BESCHREIBUNG
Publikum aud 00001111-aaaa-2222-bbbb-3333cccc4444 Identifiziert den vorgesehenen Empfänger des Tokens. Für Azure AD B2C ist die Zielgruppe die Anwendungs-ID. Ihre Anwendung sollte diesen Wert überprüfen und das Token ablehnen, wenn sie nicht übereinstimmen. Zielgruppe ist synonym für Ressource.
Emittent iss https://<tenant-name>.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/ Gibt den Sicherheitstokendienst (Security Token Service, STS) an, der das Token erstellt und zurückgibt. Außerdem wird das Verzeichnis identifiziert, in dem der Benutzer authentifiziert wurde. Ihre Anwendung sollte den Ausstelleranspruch überprüfen, um sicherzustellen, dass das Token vom entsprechenden Endpunkt stammt.
Ausgestellt um iat 1438535543 Die Zeit, zu der das Token ausgestellt wurde (dargestellt als Epochenzeit)
Ablaufzeit exp 1438539443 Die Zeit, zu der das Token ungültig wird (dargestellt als Epochenzeit). Ihre Anwendung sollte diesen Anspruch verwenden, um die Gültigkeit der Tokenlebensdauer zu überprüfen.
Nicht vor nbf 1438535543 Die Zeit, zu der das Token gültig wird (dargestellt als Epochenzeit). Diese Zeit entspricht in der Regel dem Zeitpunkt, zu dem das Token ausgestellt wurde. Ihre Anwendung sollte diesen Anspruch verwenden, um die Gültigkeit der Tokenlebensdauer zu überprüfen.
Version ver 1.0 Die Version des ID-Tokens, wie von Azure AD B2C definiert.
Codehash c_hash SGCPtt01wxwfgnYZy2VJtQ Ein Codehash, der nur dann in einem ID-Token enthalten ist, wenn das Token zusammen mit einem OAuth 2.0-Autorisierungscode ausgegeben wird. Ein Codehash kann verwendet werden, um die Authentizität eines Autorisierungscodes zu überprüfen. Weitere Informationen zum Ausführen dieser Überprüfung finden Sie in der OpenID Connect-Spezifikation.
Zugriffstokenhash at_hash SGCPtt01wxwfgnYZy2VJtQ Ein Zugriffstoken-Hash ist nur dann in einem ID-Token enthalten, wenn das Token zusammen mit einem OAuth 2.0-Zugriffstoken ausgegeben wird. Ein Zugriffstokenhash kann verwendet werden, um die Authentizität eines Zugriffstokens zu überprüfen. Weitere Informationen zum Ausführen dieser Überprüfung finden Sie in der OpenID Connect-Spezifikation
Nonce nonce 12345 Eine Nonce ist eine Strategie zum Abwehren von Tokenwiedergabeangriffe. Ihre Anwendung kann eine Nonce in einer Autorisierungsanforderung mithilfe des Abfrageparameters nonce angeben. Der Wert, den Sie in der Anfrage angeben, wird unverändert nur im nonce-Anspruch eines ID-Tokens ausgegeben. Mit diesem Anspruch kann Ihre Anwendung den Wert mit dem in der Anforderung angegebenen Wert vergleichen und verifizieren. Ihre Anwendung sollte diese Überprüfung während des ID-Tokenüberprüfungsprozesses ausführen.
Betreff sub aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb Der Prinzipal, für den das Token Informationen bestätigt (beispielsweise der Benutzer einer Anwendung). Dieser Wert ist unveränderlich und kann nicht erneut zugewiesen oder wiederverwendet werden. Es kann verwendet werden, um Autorisierungsprüfungen sicher durchzuführen, z. B. wenn das Token für den Zugriff auf eine Ressource verwendet wird. Der Anspruch „Antragsteller“ wird standardmäßig mit der Objekt-ID des Benutzers im Verzeichnis aufgefüllt.
Referenz zur Authentifizierungskontextklasse acr Nicht anwendbar Wird nur mit älteren Richtlinien verwendet.
Richtlinie für Vertrauensframeworks tfp b2c_1_signupsignin1 Der Name der Richtlinie, die zum Abrufen des ID-Tokens verwendet wurde.
Authentifizierungszeit auth_time 1438535543 Die Zeit, zu der ein Benutzer seine Anmeldeinformationen zuletzt eingegeben hat (dargestellt als Epochenzeit). Es gibt keine Diskriminierung zwischen dieser Authentifizierung als neue Anmeldung, einer SSO-Sitzung (Single Sign-On) oder einem anderen Anmeldetyp. Dies auth_time ist das letzte Mal, wenn die Anwendung (oder der Benutzer) einen Authentifizierungsversuch gegen Azure AD B2C initiiert hat. Die zum Authentifizieren verwendete Methode wird nicht unterschieden.
Umfang scp Read Die Berechtigungen, die der Ressource für ein Zugriffstoken gewährt werden. Mehrere erteilte Berechtigungen werden durch ein Leerzeichen getrennt.
Autorisierte Partei azp 975251ed-e4f5-4efd-abcb-5f1a8f566ab7 Die Anwendungs-ID der Clientanwendung, die die Anforderung initiiert hat.

Konfiguration

Die folgenden Eigenschaften werden verwendet, um die Lebensdauer von Sicherheitstoken zu verwalten, die von Azure AD B2C ausgegeben werden:

  • Lebensdauer des Zugriffs- und ID-Tokens (Minuten) – Die Lebensdauer des OAuth 2.0-Bearertokens, das für den Zugriff auf eine geschützte Ressource verwendet wird. Der Standardwert ist 60 Sekunden. Der Mindestwert ist fünf Minuten (einschließlich). Das Maximum (einschließlich) beträgt 1.440 Minuten.

  • Aktualisierungstokenlebensdauer (Tage) – Der maximale Zeitraum, vor dem ein Aktualisierungstoken verwendet werden kann, um ein neues Zugriffs- oder ID-Token abzurufen. Der Zeitraum deckt auch das Abrufen eines neuen Aktualisierungstokens ab, falls Ihrer Anwendung der Bereich offline_access gewährt wurde. Der Standardwert ist 14 Tage. Der Mindestwert ist ein Tag (einschließlich). Der Höchstwert ist 90 Tage (einschließlich).

  • Aktualisierungstoken gleitende Fensterlebensdauer (Tage) – Nach Ablauf dieses Zeitraums wird der Benutzer gezwungen, die Authentifizierung erneut zu authentifizieren, unabhängig von der Gültigkeitsdauer des zuletzt von der Anwendung erworbenen Aktualisierungstokens. Sie kann nur bereitgestellt werden, wenn der Schalter auf "Gebunden" festgelegt ist. Er muss größer oder gleich dem Wert der Aktualisierungstokenlebensdauer (Tage) sein. Wenn der Schalter auf "Kein Ablauf" festgelegt ist, können Sie keinen bestimmten Wert angeben. Der Standardwert beträgt 90 Tage. Der Mindestwert ist ein Tag (einschließlich). Das Maximum (einschließlich) beträgt 365 Tage.

Die folgenden Anwendungsfälle werden mithilfe dieser Eigenschaften aktiviert:

  • Zulassen, dass ein Benutzer unbegrenzt bei einer mobilen Anwendung angemeldet bleibt, solange der Benutzer kontinuierlich auf der Anwendung aktiv ist. Sie können die Lebensdauer des Aktualisierungstokens für das Gleitfenster (Tage) auf "Kein Ablauf " in Ihrem Anmeldebenutzerablauf festlegen.
  • Erfüllen Sie die Sicherheits- und Complianceanforderungen Ihrer Branche, indem Sie die entsprechenden Gültigkeitsdauern für Zugriffstoken festlegen.

Diese Einstellungen sind für Benutzerflows für die Kennwortzurücksetzung nicht verfügbar.

Kompatibilität

Die folgenden Eigenschaften werden verwendet, um die Tokenkompatibilität zu verwalten:

  • Ausstelleranspruch (iss) – Diese Eigenschaft identifiziert den Azure AD B2C-Mandanten, der das Token ausgestellt hat. Der Standardwert ist https://<domain>/{B2C tenant GUID}/v2.0/. Der Wert https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ enthält die IDs von sowohl dem Azure AD B2C-Mandanten als auch den Benutzerfluss, die in der Tokenanforderung verwendet wurden. Wenn Ihre Anwendung oder Bibliothek Azure AD B2C benötigt, um mit der OpenID Connect Discovery 1.0-Spezifikation kompatibel zu sein, verwenden Sie diesen Wert.

  • Antragstelleranspruch (sub): Diese Eigenschaft gibt die Entität an, für die das Token Informationen bestätigt. Der Standardwert ist ObjectID, der den sub Anspruch im Token mit der Objekt-ID des Benutzers auffüllt. Der Wert von "Nicht unterstützt" wird nur aus Gründen der Abwärtskompatibilität bereitgestellt. Es wird empfohlen, zu ObjectID zu wechseln, sobald Sie in der Lage sind.

  • Anspruch, der richtlinien-ID darstellt – Diese Eigenschaft identifiziert den Anspruchstyp, in den der in der Tokenanforderung verwendete Richtlinienname aufgefüllt wird. Der Standardwert ist tfp. Der Wert von acr wird nur aus Gründen der Abwärtskompatibilität bereitgestellt.

Pass-Through

Wenn eine Benutzerreise gestartet wird, empfängt Azure AD B2C ein Zugriffstoken von einem Identitätsanbieter. Azure AD B2C verwendet dieses Token, um Informationen über den Benutzer abzurufen. Sie aktivieren einen Anspruch in Ihrem Benutzerflow, um das Token an die Anwendungen zu übergeben, die Sie in Azure AD B2C registrieren. Ihre Anwendung muss einen empfohlenen Benutzerflow verwenden, um von der Übergabe des Tokens als Anspruch profitieren zu können.

Azure AD B2C unterstützt derzeit nur das Übergeben des Zugriffstokens von OAuth 2.0-Identitätsanbietern, die Facebook und Google enthalten. Für alle anderen Identitätsanbieter wird der Anspruch leer zurückgegeben.

Validierung

Um ein Token zu überprüfen, sollte Ihre Anwendung sowohl die Signatur als auch die Ansprüche des Tokens überprüfen. Viele Open-Source-Bibliotheken sind abhängig von Ihrer bevorzugten Sprache für die Überprüfung von JWTs verfügbar. Es wird empfohlen, diese Optionen zu untersuchen, anstatt Ihre eigene Validierungslogik zu implementieren.

Signatur überprüfen

Ein JWT enthält drei Segmente, eine Kopfzeile, einen Textkörper und eine Signatur. Das Signatursegment kann verwendet werden, um die Echtheit des Tokens zu überprüfen, damit es von Ihrer Anwendung als vertrauenswürdig eingestuft werden kann. Azure AD B2C-Token werden mit branchenübden asymmetrischen Verschlüsselungsalgorithmen wie RSA 256 signiert.

Der Header des Tokens enthält Informationen über den Schlüssel und die Verschlüsselungsmethode, die zum Signieren des Tokens verwendet wird:

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

Der Wert des alg-Anspruchs ist der Algorithmus, der zum Signieren des Tokens verwendet wurde. Der Wert des Anspruchs kid ist der öffentliche Schlüssel, mit dem das Token signiert wurde. Zu einem bestimmten Zeitpunkt kann Azure AD B2C ein Token signieren, indem eines einer gruppe von öffentlich-privaten Schlüsselpaaren verwendet wird. Azure AD B2C dreht regelmäßig den möglichen Satz von Schlüsseln. Ihre Anwendung sollte so geschrieben werden, dass diese Schlüsseländerungen automatisch behandelt werden. Eine angemessene Häufigkeit für die Überprüfung auf Updates für die öffentlichen Schlüssel, die von Azure AD B2C verwendet werden, beträgt alle 24 Stunden. Um unerwartete Schlüsseländerungen zu behandeln, sollte Ihre Anwendung so programmiert sein, dass sie die öffentlichen Schlüssel erneut abruft, falls sie einen unerwarteten kid-Wert erhält.

Azure AD B2C verfügt über einen OpenID Connect-Metadatenendpunkt. Mithilfe dieses Endpunkts können Anwendungen Zur Laufzeit Informationen zu Azure AD B2C anfordern. Diese Informationen umfassen Endpunkte, Tokeninhalte und Tokensignaturschlüssel. Ihr Azure AD B2C-Mandant enthält ein JSON-Metadatendokument für jede Richtlinie. Das Metadatendokument ist ein JSON-Objekt, das mehrere nützliche Informationen enthält. Die Metadaten enthalten jwks_uri, wodurch der Speicherort der Gruppe von öffentlichen Schlüsseln angegeben wird, die zum Signieren von Token verwendet werden. Dieser Speicherort wird hier bereitgestellt, aber es empfiehlt sich, den Speicherort dynamisch mithilfe des Metadatendokuments abzurufen und jwks_uri zu analysieren:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Das JSON-Dokument, das sich unter dieser URL befindet, enthält alle öffentlichen Schlüsselinformationen, die zu einem bestimmten Zeitpunkt verwendet werden. Ihre App kann den kid Anspruch im JWT-Header verwenden, um den öffentlichen Schlüssel im JSON-Dokument auszuwählen, mit dem ein bestimmtes Token signiert wird. Anschließend kann die Signaturüberprüfung mithilfe des richtigen öffentlichen Schlüssels und des angegebenen Algorithmus ausgeführt werden.

Das Metadatendokument für die Richtlinie B2C_1_signupsignin1 im Mandaten contoso.onmicrosoft.com befindet sich hier:

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Um zu ermitteln, welche Richtlinie zum Signieren eines Tokens verwendet wurde (und wo die Metadaten angefordert werden sollen), haben Sie zwei Optionen. Zunächst einmal ist der Richtlinienname im Token im tfp-Anspruch (Standard) oder im acr-Anspruch (wie konfiguriert) enthalten. Sie können Ansprüche aus dem Hauptteil des JWT analysieren, indem Sie eine Base64-Decodierung auf den Hauptteil anwenden und die sich ergebende JSON-Zeichenfolge deserialisieren. Der Anspruch tfp bzw. acr ist der Name der Richtlinie, die zum Ausstellen des Tokens verwendet wurde. Die andere Option besteht darin, die Richtlinie im Wert des state Parameters zu codieren, wenn Sie die Anforderung ausgeben, und decodieren Sie sie dann, um zu bestimmen, welche Richtlinie verwendet wurde. Beide Methoden sind gültig.

Azure AD B2C verwendet den RS256-Algorithmus, der auf der RFC 3447-Spezifikation basiert. Der öffentliche Schlüssel besteht aus zwei Komponenten: dem RSA-Modulus (n) und dem öffentlichen RSA-Exponenten (e). Sie können n- und e-Werte programmgesteuert in ein Zertifikatformat für die Tokenüberprüfung konvertieren.

Eine Beschreibung der Ausführung der Signaturüberprüfung liegt außerhalb des Gültigkeitsbereichs dieses Dokuments. Viele Open-Source-Bibliotheken stehen zur Verfügung, damit Sie ein Token überprüfen können.

Überprüfen von Ansprüchen

Wenn Ihre Anwendungen oder API ein ID-Token empfängt, sollte sie auch mehrere Überprüfungen der Ansprüche im ID-Token durchführen. Die folgenden Ansprüche sollten überprüft werden:

  • Audience – Überprüft, ob das ID-Token für Ihre Anwendung bestimmt war.
  • not before und expiration time: Hiermit wird überprüft, ob das ID-Token abgelaufen ist.
  • issuer – Überprüft, ob das Token von Azure AD B2C an Ihre Anwendung ausgestellt wurde.
  • nonce – Eine Strategie für die Risikominderung des Token-Replay-Angriffs.

Eine vollständige Liste der Überprüfungen, die Ihre Anwendung ausführen sollte, finden Sie in der OpenID Connect-Spezifikation.

Verwandte Inhalte

Erfahren Sie mehr über die Verwendung von Zugriffstoken.