Freigeben über

Anfordern eines Zugriffstokens 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.

Ein Zugriffstoken enthält Ansprüche, die Sie in Azure Active Directory B2C (Azure AD B2C) verwenden können, um die erteilten Berechtigungen für Ihre APIs zu identifizieren. Um einen Ressourcenserver aufzurufen, muss die HTTP-Anforderung ein Zugriffstoken enthalten. Ein Zugriffstoken wird in den Antworten von Azure AD B2C als access_token bezeichnet.

In diesem Artikel erfahren Sie, wie Sie ein Zugriffstoken für eine Webanwendung und 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 andere downstream-Web-API aufrufen muss, die beide durch Azure AD B2C gesichert ist. Dieses Szenario ist in Clients üblich, die über ein Web-API-Back-End verfügen, das wiederum einen anderen Dienst aufruft. 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 On-Behalf-Of-Fluss. Der On-Behalf-Of-Fluss wird derzeit jedoch nicht in Azure AD B2C implementiert. Obwohl "On-Behalf-Of" für Anwendungen funktioniert, die in der Microsoft Entra-ID registriert sind, funktioniert es nicht für Anwendungen, die in Azure AD B2C registriert sind, unabhängig vom Mandanten (Microsoft Entra ID oder Azure AD B2C), der die Token ausgibt.

Voraussetzungen

Geltungsbereiche

Bereiche bieten eine Möglichkeit zum Verwalten von Berechtigungen für geschützte Ressourcen. Wenn ein Zugriffstoken angefordert wird, muss die Clientanwendung die gewünschten Berechtigungen im Bereichsparameter der Anforderung angeben. 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. Beispielsweise könnten Benutzer der Web-API sowohl Lese- als auch Schreibzugriff haben, oder Benutzer der Web-API haben möglicherweise nur Lesezugriff. Um mehrere Berechtigungen in derselben Anforderung zu erwerben, können Sie mehrere Einträge im einzelnen Bereichsparameter der Anforderung hinzufügen, getrennt durch Leerzeichen.

Das folgende Beispiel zeigt Bereiche, die in einer URL decodiert wurden:

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

Das folgende Beispiel zeigt Bereiche, die in einer URL codiert sind:

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

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

OpenID Connect-Bereiche

Der OpenID Connect-Standard gibt mehrere spezielle Bereichswerte an. Die folgenden Bereiche stellen die Berechtigung für den Zugriff auf das Profil des Benutzers dar:

  • openid – Fordert ein ID-Token an.
  • offline_access – Fordert ein Aktualisierungstoken mithilfe von Authentifizierungscodeflüssen an.
  • 00000000-0000-0000-0000-000000000000 - Die Verwendung der Client-ID als Gültigkeitsbereich gibt an, dass Ihre App ein Zugriffstoken benötigt, das gegen Ihren eigenen Dienst oder Ihre Web-API verwendet werden kann, die durch dieselbe Client-ID repräsentiert wird.

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 schlägt die /authorize Anforderung fehl.

Anfordern eines Tokens

Zum Anfordern eines Zugriffstokens benötigen Sie einen Autorisierungscode. Im Folgenden sehen Sie ein Beispiel für eine Anforderung an den /authorize Endpunkt für einen Autorisierungscode:

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> – Der Name Ihres 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> – Der Name Ihrer benutzerdefinierten Richtlinie oder des Benutzerflusses.
  • <application-ID> – Der Anwendungsbezeichner der Webanwendung, die Sie registriert haben, um den Benutzerablauf zu unterstützen.
  • <application-ID-URI> – Der Anwendungsbezeichner-URI, den Sie unter "Verfügbarmachen eines API-Blatts der Clientanwendung" festgelegt haben.
  • <scope-name> – Der Name des Bereichs, den Sie unter "Verfügbarmachen" eines API-Blatts der Clientanwendung hinzugefügt haben.
  • <redirect-uri> – Der Umleitungs-URI , den Sie beim Registrieren der Clientanwendung eingegeben haben.

Um die Funktionsweise der Anforderung zu spüren, fügen Sie die Anforderung in Ihren Browser ein, und führen Sie sie aus.

Dies ist der interaktive Teil des Flusses, in dem Sie Maßnahmen ergreifen. Sie werden aufgefordert, den Workflow des Benutzerflows abzuschließen. Dies kann die Eingabe Ihres Benutzernamens und Kennworts in ein Anmeldeformular oder eine beliebige andere Anzahl von Schritten umfassen. Die schritte, die Sie ausführen, hängen davon ab, wie der Benutzerfluss definiert ist.

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

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

Nachdem Sie den Autorisierungscode erfolgreich empfangen haben, können Sie ihn verwenden, um ein Zugriffstoken anzufordern. Die Parameter befinden sich im Textkörper 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 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..."
}

https://jwt.ms Wenn Sie das zurückgegebene Zugriffstoken untersuchen, sollte das folgende Beispiel ähnlich aussehen:

{
  "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

  • Last updated on