Share via

Anfordern eines Zugriffstokens in Azure Active Directory B2C

  • Artikel

Ein Zugriffstoken enthält Ansprüche, mit denen Sie in Azure Active Directory B2C (Azure AD B2C) die gewährten Berechtigungen für Ihre APIs identifizieren können. Zum Aufrufen eines Ressourcenservers muss die HTTP-Anforderung ein Zugriffstoken enthalten. Zugriffstoken werden in den Antworten von Azure AD B2C als access_token angegeben.

In diesem Artikel wird erläutert, wie Sie ein Zugriffstoken für eine Webanwendung und eine Web-API anfordern. Weitere Informationen zu Token in Azure AD B2C finden Sie in der Übersicht über Token in Azure Active Directory B2C.

Hinweis

Web-API-Ketten (On-Behalf-Of) werden von Azure AD B2C nicht unterstützt. Viele Architekturen enthalten eine Web-API, die eine weitere nachgelagerte Web-API aufrufen muss, die beide durch Azure AD B2C geschützt ist. Dieses Szenario kommt häufig bei Clients mit einem Web-API-Back-End vor, über das wiederum ein anderer Dienst aufgerufen wird. Dieses Szenario der verketteten Web-API kann mithilfe der Berechtigung für Anmeldeinformationen über den OAuth 2.0-JWT-Bearer unterstützt werden, auch bekannt als „Im Auftrag von“-Ablauf. Der „Im Auftrag von“-Ablauf ist in Azure AD B2C derzeit noch nicht implementiert. „Im Auftrag von“ funktioniert zwar für Anwendungen, die in Microsoft Entra ID registriert sind, jedoch nicht für solche, die in Azure AD B2C registriert sind – und zwar unabhängig vom Mandanten (Microsoft Entra ID oder Azure AD B2C), der die Token ausstellt.

Voraussetzungen

Bereiche

Bereiche ermöglichen die Verwaltung von Berechtigungen für geschützte Ressourcen. Bei der Anforderung eines Zugriffstokens müssen in der Clientanwendung im scope-Parameter der Anforderung die gewünschten Berechtigungen angegeben werden. Um z. B. den Bereichswertread für die API mit dem App-ID-URIhttps://contoso.onmicrosoft.com/api anzugeben, lautet der Bereich https://contoso.onmicrosoft.com/api/read.

Bereiche werden von der Web-API verwendet, um eine bereichsbasierte Zugriffssteuerung zu implementieren. Benutzer der Web-API können beispielsweise über Lese- und Schreibzugriff oder nur über Lesezugriff verfügen. Um mehrere Berechtigungen in derselben Anforderung zu beziehen, können Sie mehrere durch Leerzeichen getrennte Einträge in einem einzelnen scope-Parameter der Anforderung hinzufügen.

Im folgenden Beispiel sind decodierte Bereiche in einer URL dargestellt:

scope=https://contoso.onmicrosoft.com/api/read openid offline_access

Im folgenden Beispiel sind codierte Bereiche in einer URL dargestellt:

scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access

Wenn Sie mehr Bereiche als die für die Clientanwendung erteilten Berechtigungen anfordern, wird der Aufruf erfolgreich ausgeführt, wenn mindestens eine Berechtigung erteilt wird. Der scp-Anspruch im resultierenden Zugriffstoken wird nur mit den Berechtigungen gefüllt, die erfolgreich erteilt wurden.

OpenID Connect-Bereiche

Mit dem OpenID Connect-Standard werden mehrere spezielle Bereichswerte angegeben. Die folgenden Bereiche stellen die Berechtigung für den Zugriff auf das Profil des Benutzers dar:

  • openid: Hierdurch wird ein ID-Token angefordert.
  • offline_access: Hierdurch wird ein Aktualisierungstoken (mithilfe von Autorisierungscodeabläufen) angefordert.
  • 00000000-0000-0000-0000-000000000000 – Mit der Verwendung der Client-ID als Bereich wird angegeben, dass für Ihre App ein Zugriffstoken erforderlich ist, das für Ihren eigenen Dienst oder die Web-API mit derselben Client-ID verwendet werden kann.

Wenn der Parameter response_type in einer /authorize-Anforderung token enthält, muss der Parameter scope mindestens einen Ressourcenbereich (außer openid und offline_access) enthalten, für den Berechtigungen erteilt werden. Andernfalls wird die /authorize-Anforderung abgelehnt.

Anfordern eines Tokens

Zur Anforderung eines Zugriffstokens benötigen Sie einen Autorisierungscode. Es folgt ein Beispiel für eine Anforderung eines Autorisierungscodes an den /authorize-Endpunkt.

GET https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=<application-ID-URI>/<scope-name>
&response_type=code

Ersetzen Sie die Werte in der Abfragezeichenfolge wie folgt:

  • <tenant-name>: Name des Azure AD B2C-Mandanten. Wenn Sie eine benutzerdefinierte Domäne verwenden, ersetzen Sie tenant-name.b2clogin.com durch Ihre Domäne, z. B. contoso.com.
  • <policy-name>: Name der benutzerdefinierten Richtlinie oder des Benutzerflows.
  • <application-ID>: Anwendungs-ID der Webanwendung, die Sie zur Unterstützung des Benutzerflows registriert haben.
  • <application-ID-URI>: Der Anwendungsbezeichner-URI, den Sie in der Clientanwendung auf dem Blatt Eine API verfügbar machen festgelegt haben.
  • <scope-name>: Der Name des Bereichs, den Sie in der Clientanwendung auf dem Blatt Eine API verfügbar machen hinzugefügt haben.
  • <redirect-uri>: Der Umleitungs-URI, den Sie bei der Registrierung der Clientanwendung eingegeben haben.

Fügen Sie die Anforderung in Ihren Browser ein, und führen Sie sie aus, um ein Gefühl für die Funktionsweise der Anforderung zu erhalten.

Dies ist der interaktive Teil des Flows, während dessen Sie Aktionen durchführen. Sie werden aufgefordert, den Workflow des Benutzerflows abzuschließen. Dies kann die Eingabe Ihres Benutzernamens und Kennworts in einem Anmeldeformular oder eine beliebige andere Anzahl von Schritten sein. Welche Schritte Sie ausführen, hängt davon ab, wie der Benutzerflow definiert ist.

Die Antwort mit dem Autorisierungscode sollte dem folgenden Beispiel ähneln:

https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...

Nach dem Empfang des Autorisierungscodes können Sie über diesen Code ein Zugriffstoken anfordern. Die Parameter befinden sich im Text der HTTP POST-Anforderung:

POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<application-ID>
&scope=<application-ID-URI>/<scope-name>
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=2hMG2-_:y12n10vwH...

Wenn Sie diese POST-HTTP-Anforderung testen möchten, können Sie einen beliebigen HTTP-Client wie Microsoft PowerShell oder Postman verwenden.

Eine erfolgreiche Tokenantwort sieht wie folgt aus:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrN...",
    "token_type": "Bearer",
    "not_before": 1549647431,
    "expires_in": 3600,
    "expires_on": 1549651031,
    "resource": "f2a76e08-93f2-4350-833c-965c02483b11",
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiJjNjRhNGY3ZC0zMDkxLTRjNzMtYTcyMi1hM2YwNjk0Z..."
}

Bei Verwendung von https://jwt.ms zum Überprüfen des zurückgegebenen Zugriffstokens sollte etwa die folgende Ausgabe angezeigt werden:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dl..."
}.{
  "iss": "https://contoso0926tenant.b2clogin.com/c64a4f7d-3091-4c73-a7.../v2.0/",
  "exp": 1549651031,
  "nbf": 1549647431,
  "aud": "f2a76e08-93f2-4350-833c-965...",
  "oid": "1558f87f-452b-4757-bcd1-883...",
  "sub": "1558f87f-452b-4757-bcd1-883...",
  "name": "David",
  "tfp": "B2C_1_signupsignin1",
  "nonce": "anyRandomValue",
  "scp": "read",
  "azp": "38307aee-303c-4fff-8087-d8d2...",
  "ver": "1.0",
  "iat": 1549647431
}.[Signature]

Nächste Schritte