Anreichern von Token mit Ansprüchen aus externen Quellen mithilfe von API-Connectors

Sie können API-Connectors verwenden, die auf den Schritt Vor dem Senden des Tokens (Vorschau) angewendet werden, um Token für Ihre Anwendungen mit Informationen aus externen Quellen zu bereichern. Wenn sich ein Benutzer anmeldet oder registriert, ruft Azure AD B2C den API-Endpunkt auf, der im API-Connector konfiguriert ist. Dieser kann Informationen über einen Benutzer in nachgelagerten Diensten wie Clouddiensten, benutzerdefinierten Benutzerspeichern, benutzerdefinierten Berechtigungssystemen, Legacy-Identitätssystemen und mehr abfragen.

Sie können einen API-Endpunkt mithilfe eines unserer Beispiele erstellen.

Voraussetzungen

• Ein API-Endpunkt. Sie können einen API-Endpunkt mithilfe eines unserer Beispiele erstellen.

Erstellen eines API-Connectors

Um einen API-Connector zu verwenden, erstellen Sie zuerst den API-Connector und aktivieren ihn dann in einem Benutzerablauf.

1. Melden Sie sich beim Azure-Portal an.

2. Wählen Sie unter Azure-DiensteAzure AD B2C aus.

3. Wählen Sie API-Connectors aus, und wählen Sie dann "Neuer API-Connector" aus.

   

4. Geben Sie einen Anzeigenamen für den Aufruf an. Beispiel: Anreichern von Token aus externer Quelle.

5. Geben Sie die Endpunkt-URL für den API-Aufruf an.

6. Wählen Sie den Authentifizierungstyp aus, und konfigurieren Sie die Authentifizierungsinformationen zum Aufrufen Ihrer API. Erfahren Sie, wie Sie Ihren API-Connector sichern.

   

7. Wählen Sie Speichern aus.

Aktivieren des API-Connectors in einem Benutzerablauf

Führen Sie die folgenden Schritte aus, um einem Registrierungsbenutzerablauf einen API-Connector hinzuzufügen.

1. Melden Sie sich beim Azure-Portal an.

2. Wählen Sie unter Azure-DiensteAzure AD B2C aus.

3. Wählen Sie Benutzerflüsse aus, und wählen Sie dann den Benutzerfluss aus, dem Sie den API-Connector hinzufügen möchten.

4. Wählen Sie API-Connectors aus, und wählen Sie dann den API-Endpunkt aus, den Sie beim Schritt Vor dem Senden des Tokens (Vorschau) im Benutzerablauf aufrufen möchten.

   

5. Wählen Sie Speichern aus.

Dieser Schritt ist nur für Registrierungs- und Anmeldevorgänge (empfohlen), Registrierung (Empfohlen) und Benutzerflüsse (empfohlen) vorhanden.

In diesem Schritt an die API gesendete Beispielanforderung

Ein API-Connector in diesem Schritt wird aufgerufen, wenn ein Token während der Anmeldungen und Registrierungen ausgestellt werden soll. Ein API-Connector wird als HTTP POST-Anforderung dargestellt und sendet Benutzerattribute („Ansprüche“) als Schlüssel-Wert-Paare in einem JSON-Text. Attribute werden ähnlich wie Microsoft Graph-Benutzereigenschaften serialisiert.

POST <API-endpoint>
Content-type: application/json
{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "client_id": "00001111-aaaa-2222-bbbb-3333cccc4444",
 "step": "PreTokenIssuance",
 "ui_locales":"en-US"
}

Die Ansprüche, die an die API gesendet werden, hängen von den für den Benutzer definierten Informationen ab. Nur Benutzereigenschaften und benutzerdefinierte Attribute, die unterAzure AD B2C>Benutzerattribute aufgeführt sind, können in der Anforderung gesendet werden. Benutzerdefinierte Attribute sind im Format extension_<extensions-app-id>_CustomAttribute im Verzeichnis vorhanden. Die API sollte den Empfang von Ansprüchen in diesem serialisierten Format erwarten. Weitere Informationen zu benutzerdefinierten Attributen finden Sie unter Definieren von benutzerdefinierten Attributen in Azure AD B2C. In der Regel werden diese Anträge zusätzlich in allen Anfragen für diesen Schritt gesendet.

• UI-Gebietsschemas („ui_locales“): Die auf dem Gerät konfigurierten Gebietsschemas eines Endbenutzers. Kann von Ihrer API verwendet werden, um internationalisierte Antworten zurückzugeben.
• Schritt ('step'): Der Schritt oder Punkt im Benutzerflow, für den der API-Connector aufgerufen wurde. Wert für diesen Schritt lautet '
• Client-ID ('client_id') – Der appId Wert der Anwendung, für die ein Endbenutzer sich in einem Benutzerablauf authentifiziert. Dabei handelt es sich nicht um den appId-Wert der Ressourcenanwendung in Zugriffstoken.
• objectId – Der Bezeichner des Benutzers. Sie können dies verwenden, um nachgelagerte Dienste nach Informationen zum Benutzer abzufragen.

Von der Web-API in diesem Schritt erwartete Antworttypen

Wenn die Web-API während eines Benutzerablaufs eine HTTP-Anforderung von Microsoft Entra-ID empfängt, kann sie eine "Fortsetzungsantwort" zurückgeben.

Fortsetzungsantwort

Eine Fortsetzungsantwort gibt an, dass der Benutzerablauf mit dem nächsten Schritt fortfahren soll: Ausstellen des Tokens. In einer Fortsetzungsantwort kann die API zusätzliche Ansprüche zurückgeben. Ein von der API zurückgegebener Anspruch, den Sie im Token zurückgeben möchten, muss ein integrierter Anspruch oder ein benutzerdefiniertes Attribut sein und in der Anwendungsanspruchskonfiguration des Benutzerablaufs ausgewählt werden. Der Anspruchswert im Token wird von der API und nicht vom Wert im Verzeichnis zurückgegeben. Einige Anspruchswerte können von der API-Antwort nicht überschrieben werden. Ansprüche, die von der API zurückgegeben werden können, entsprechen den Ansprüchen unter Benutzerattribute (mit Ausnahme von email).

Beispielantwort

Beispiel für eine Fortsetzungsantwort

HTTP/1.1 200 OK
Content-type: application/json
{
    "version": "1.0.0",
    "action": "Continue",
    "postalCode": "12349", // return claim
    "extension_<extensions-app-id>_CustomAttribute": "value" // return claim
}

In diesem Szenario bereichern wir die Tokendaten des Benutzers durch die Integration in einen Unternehmens-Branchenworkflow. Während der Registrierung oder Anmeldung mit einem lokalen oder Verbundkonto ruft Azure AD B2C eine REST-API auf, um die erweiterten Profildaten des Benutzers aus einer Remotedatenquelle abzurufen. In diesem Beispiel sendet Azure AD B2C den eindeutigen Bezeichner des Benutzers, die objectId. Die REST-API gibt dann den Kontostand des Benutzers (eine Zufallszahl) zurück. Verwenden Sie dieses Beispiel als Ausgangspunkt für die Integration in Ihr eigenes CRM-System, eine Marketingdatenbank oder einen beliebigen Branchenworkflow. Sie können die Interaktion auch als technisches Validierungsprofil entwerfen. Dies ist geeignet, wenn die REST-API Daten auf dem Bildschirm überprüft und Ansprüche zurückgibt. Weitere Informationen finden Sie unter Anleitung: Hinzufügen eines API-Konnektors zu einem Registrierungsbenutzerfluss.

Voraussetzungen

• Führen Sie die Schritte in "Erste Schritte mit benutzerdefinierten Richtlinien" aus. Sie sollten eine funktionierende benutzerdefinierte Richtlinie für die Registrierung und Anmeldung bei lokalen Konten besitzen.
• Erfahren Sie, wie Sie REST-API-Anspruchsbörsen in Ihre benutzerdefinierte Azure AD B2C-Richtlinie integrieren.

Vorbereiten eines REST-API-Endpunkts

Für diese exemplarische Vorgehensweise sollten Sie über eine REST-API verfügen, die überprüft, ob die Azure AD B2C objectId eines Benutzers in Ihrem Back-End-System registriert ist. Bei der Registrierung gibt die REST-API den Kontostand zurück. Andernfalls registriert die REST-API das neue Konto im Verzeichnis und gibt den Startsaldo 50.00zurück. Der folgende JSON-Code veranschaulicht die Daten, die Azure AD B2C an Ihren REST-API-Endpunkt senden.

{
    "objectId": "User objectId",
    "lang": "Current UI language"
}

Nachdem Ihre REST-API die Daten überprüft hat, muss sie einen HTTP 200 (OK) mit den folgenden JSON-Daten zurückgeben:

{
    "balance": "760.50"
}

Das Setup des REST-API-Endpunkts liegt außerhalb des Umfangs dieses Artikels. Wir haben ein Azure Functions-Beispiel erstellt. Sie können auf den vollständigen Azure-Funktionscode auf GitHub zugreifen.

Definieren von Ansprüchen

Ein Anspruch bietet eine temporäre Speicherung von Daten während der Ausführung einer Azure AD B2C-Richtlinie. Sie können Ansprüche im Abschnitt "Anspruchsschema " deklarieren.

1. Öffnen Sie die Erweiterungsdatei Ihrer Richtlinie. Beispiel: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
2. Suchen Sie nach dem BuildingBlocks-Element . Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.
3. Suchen Sie das ClaimsSchema-Element . Wenn das Element nicht vorhanden ist, fügen Sie es hinzu.
4. Fügen Sie dem ClaimsSchema-Element die folgenden Ansprüche hinzu.

<ClaimType Id="balance">
  <DisplayName>Your Balance</DisplayName>
  <DataType>string</DataType>
</ClaimType>
<ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Hinzufügen des technischen Profils der RESTful-API

Ein RESTful-technisches Profil bietet Unterstützung für die Interoperabilität mit Ihrem eigenen RESTful-Dienst. Azure AD B2C sendet Daten an den RESTful-Dienst in einer InputClaims Sammlung und empfängt Daten zurück in einer OutputClaims Sammlung. Suchen Sie das ClaimsProviders-Element in Ihrer TrustFrameworkExtensions.xml Datei, und fügen Sie einen neuen Anspruchsanbieter wie folgt hinzu:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-GetProfile">
      <DisplayName>Get user extended profile Azure Function web hook</DisplayName>
      <Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.RestfulProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
      <Metadata>
        <!-- Set the ServiceUrl with your own REST API endpoint -->
        <Item Key="ServiceUrl">https://your-account.azurewebsites.net/api/GetProfile?code=your-code</Item>
        <Item Key="SendClaimsIn">Body</Item>
        <!-- Set AuthenticationType to Basic or ClientCertificate in production environments -->
        <Item Key="AuthenticationType">None</Item>
        <!-- REMOVE the following line in production environments -->
        <Item Key="AllowInsecureAuthInProduction">true</Item>
      </Metadata>
      <InputClaims>
        <!-- Claims sent to your REST API -->
        <InputClaim ClaimTypeReferenceId="objectId" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="balance" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

In diesem Beispiel wird userLanguage innerhalb der JSON-Nutzlast als lang an den REST-Dienst gesendet. Der Wert des userLanguage Anspruchs enthält die aktuelle Benutzersprachen-ID. Weitere Informationen finden Sie unter Claim Resolver.

Konfigurieren des technischen PROFILs der RESTful-API

Legen Sie nach der Bereitstellung Der REST-API die Metadaten des REST-GetProfile technischen Profils so fest, dass sie Ihre eigene REST-API widerspiegeln, einschließlich:

• ServiceUrl verwenden. Legen Sie die URL des REST-API-Endpunkts fest.
• SendClaimsIn. Geben Sie an, wie die Eingabeansprüche an den RESTful-Anspruchsanbieter gesendet werden.
• AuthenticationType. Festlegen Sie den Authentifizierungstyp, der vom RESTful-Anspruchsanbieter ausgeführt wird, wie Basic oder ClientCertificate.
• AllowInsecureAuthInProduction. Stellen Sie in einer Produktionsumgebung sicher, dass diese Metadaten auf false gesetzt werden.

Weitere Konfigurationen finden Sie in den METADATEN des RESTful-technischen Profils . Die obigen AuthenticationType Kommentare und AllowInsecureAuthInProduction angeben Änderungen, die Sie vornehmen sollten, wenn Sie zu einer Produktionsumgebung wechseln. Informationen zum Sichern Ihrer RESTful-APIs für die Produktion finden Sie unter Secure your RESTful API.

Hinzufügen eines Orchestrierungsschritts

User Journeys geben explizite Pfade an, über die eine Richtlinie einer Anwendung der vertrauenden Seite die gewünschten Ansprüche für einen Benutzer abrufen kann. Eine User Journey wird als Orchestrierungssequenz dargestellt, die für eine erfolgreiche Transaktion durchlaufen werden muss. Sie können Orchestrierungsschritte hinzufügen oder subtrahieren. In diesem Fall fügen Sie einen neuen Orchestrierungsschritt hinzu, der verwendet wird, um die Informationen zu erweitern, die der Anwendung bereitgestellt werden, nachdem sich der Benutzer durch den REST-API-Aufruf angemeldet oder registriert hat.

1. Öffnen Sie die Basisdatei Ihrer Richtlinie. Beispiel: SocialAndLocalAccounts/TrustFrameworkBase.xml.
2. Suchen Sie nach dem <UserJourneys> Element. Kopieren Sie das gesamte Element, und löschen Sie es.
3. Öffnen Sie die Erweiterungsdatei Ihrer Richtlinie. Beispiel: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
4. Fügen Sie die <UserJourneys> Datei in die Erweiterungsdatei nach dem Schließen des <ClaimsProviders> Elements ein.
5. Suchen Sie <UserJourney Id="SignUpOrSignIn">, und fügen Sie den folgenden Orchestrierungsschritt vor dem letzten hinzu.

   <OrchestrationStep Order="7" Type="ClaimsExchange">
     <ClaimsExchanges>
       <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
     </ClaimsExchanges>
   </OrchestrationStep>
   

6. Umstrukturieren Sie den letzten Orchestrierungsschritt, indem Sie Order in 8 ändern. Die letzten beiden Orchestrierungsschritte sollten wie folgt aussehen:

   <OrchestrationStep Order="7" Type="ClaimsExchange">
     <ClaimsExchanges>
       <ClaimsExchange Id="RESTGetProfile" TechnicalProfileReferenceId="REST-GetProfile" />
     </ClaimsExchanges>
   </OrchestrationStep>
   <OrchestrationStep Order="8" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
   

7. Wiederholen Sie die letzten beiden Schritte für die Benutzerabläufe "ProfileEdit" und "PasswordReset".

Einschließen eines Anspruchs in das Token

Um den Anspruch balance an die Anwendung der vertrauenden Seite zurückzugeben, fügen Sie der Datei SocialAndLocalAccounts/SignUpOrSignIn.xml einen Ausgabeanspruch hinzu. Durch Hinzufügen eines Ausgabeanspruchs wird der Anspruch nach einer erfolgreichen User Journey in das Token ausgegeben und an die Anwendung gesendet. Ändern Sie im Abschnitt für die vertrauende Seite das Element des technischen Profils, um balance als Ausgabeanspruch hinzuzufügen.

<RelyingParty>
  <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
  <TechnicalProfile Id="PolicyProfile">
    <DisplayName>PolicyProfile</DisplayName>
    <Protocol Name="OpenIdConnect" />
    <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="displayName" />
      <OutputClaim ClaimTypeReferenceId="givenName" />
      <OutputClaim ClaimTypeReferenceId="surname" />
      <OutputClaim ClaimTypeReferenceId="email" />
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
      <OutputClaim ClaimTypeReferenceId="identityProvider" />
      <OutputClaim ClaimTypeReferenceId="tenantId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:TenantObjectId}" />
      <OutputClaim ClaimTypeReferenceId="balance" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Wiederholen Sie diesen Schritt für die ProfileEdit.xml und PasswordReset.xml Benutzerrouten. Speichern Sie die geänderten Dateien: TrustFrameworkBase.xml, und TrustFrameworkExtensions.xml, SignUpOrSignin.xml, ProfileEdit.xmlund PasswordReset.xml.

Testen der benutzerdefinierten Richtlinie

1. Melden Sie sich beim Azure-Portal an.
2. Wenn Sie Zugriff auf mehrere Mandanten haben, wählen Sie im oberen Menü das Symbol "Einstellungen" aus, um im Menü "Verzeichnisse + Abonnements " zu Ihrem Microsoft Entra-Mandanten zu wechseln.
3. Wählen Sie "Alle Dienste " in der oberen linken Ecke des Azure-Portals aus, und suchen Sie dann nach App-Registrierungen, und wählen Sie sie aus.
4. Wählen Sie "Identity Experience Framework" aus.
5. Wählen Sie " Benutzerdefinierte Richtlinie hochladen" aus, und laden Sie dann die geänderten Richtliniendateien hoch: TrustFrameworkBase.xml, und TrustFrameworkExtensions.xml, SignUpOrSignin.xml, ProfileEdit.xmlund PasswordReset.xml.
6. Wählen Sie die Registrierungs- oder Anmelderichtlinie aus, die Sie hochgeladen haben, und klicken Sie auf die Schaltfläche " Jetzt ausführen ".
7. Sie sollten sich mit einer E-Mail-Adresse oder einem Facebook-Konto anmelden können.
8. Das an Ihre Anwendung zurückgesendete Token enthält den balance Claim.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584961516,
  "nbf": 1584957916,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "11112222-bbbb-3333-cccc-4444dddd5555",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584957916,
  "auth_time": 1584957916,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "balance": "202.75"
  ...
}

Bewährte Methoden und Problembehandlungen

Verwenden von serverlosen Cloudfunktionen

Serverlose Funktionen (z. B. HTTP-Trigger in Azure Functions) bieten eine Möglichkeit zum Erstellen von API-Endpunkten, die mit dem API-Connector verwendet werden. Mit den serverlosen Cloudfunktionen können auch andere Web-APIs, Datenspeicher und andere Clouddienste für komplexere Szenarien aufgerufen werden.

Bewährte Methoden

Stellen Sie Folgendes sicher:

• Ihre API entspricht den API-Anforderungs- und -Antwortverträgen, wie dies weiter oben beschrieben ist.
• Die Endpunkt-URL des API-Connectors verweist auf den richtigen API-Endpunkt.
• In Ihrer API wird explizit auf NULL-Werte der empfangenen notwendigen Ansprüche geprüft.
• Ihre API implementiert eine Authentifizierungsmethode, die im sicheren API-Connector beschrieben ist.
• Ihre API antwortet so schnell wie möglich, um eine flüssige Darstellung für den Benutzer zu gewährleisten.
  • Azure AD B2C wartet maximal 20 Sekunden , um eine Antwort zu erhalten. Wird keine empfangen, wird ein weiterer Versuch (Wiederholung) unternommen, die API aufzurufen.
  • Wenn Sie eine serverlose Funktion oder einen skalierbaren Webdienst verwenden, verwenden Sie einen Hostingplan, der die API in der Produktion "wach" oder "warm" hält. Für Azure-Funktionen wird empfohlen, mindestens den Premium-Plan in der Produktion zu verwenden.
• Stellen Sie die Hochverfügbarkeit Ihrer API sicher.
• Überwachen und optimieren Sie die Leistung von nachgelagerten APIs, Datenbanken oder anderen Abhängigkeiten Ihrer API.

Verwenden von Protokollierung

Verwenden von serverlosen Cloudfunktionen

Serverlose Funktionen (z. B. HTTP-Trigger in Azure Functions) bieten eine Möglichkeit zum Erstellen von API-Endpunkten, die mit dem API-Connector verwendet werden. Mit den serverlosen Cloudfunktionen können auch andere Web-APIs, Datenspeicher und andere Clouddienste für komplexere Szenarien aufgerufen werden.

Verwenden der Protokollierung

Üblicherweise ist es nützlich, die von Ihrem Web-API-Dienst aktivierten Protokollierungstools, etwa Application Insights, zu verwenden, um Ihre API auf unerwartete Fehlercodes, Ausnahmen und schlechte Leistung zu überwachen.

• Überwachen Sie auf HTTP-Statuscodes, die weder HTTP 200 noch 400 sind.
• Der HTTP-Statuscode 401 oder 403 kennzeichnet in der Regel, dass ein Problem mit Ihrer Authentifizierung vorliegt. Überprüfen Sie die Authentifizierungsschicht Ihrer API und die entsprechende Konfiguration im API-Connector.
• Verwenden Sie bei Bedarf in der Entwicklung aggressivere Protokollierungsebenen (z. B. „trace“ oder „debug“).
• Überwachen Sie Ihre API hinsichtlich langer Antwortzeiten.

Darüber hinaus protokolliert Azure AD B2C Metadaten zu den API-Transaktionen, die während der Benutzerauthentifizierung über einen Benutzerablauf auftreten. Um diese zu finden:

1. Wechseln sie zu Azure AD B2C
2. Wählen Sie unter "Aktivitäten" die Option "Überwachungsprotokolle" aus.
3. Filtern Sie die Listenansicht: Wählen Sie für "Datum" das gewünschte Zeitintervall aus, und wählen Sie für "Aktivität" eine API aus, die als Teil eines Benutzerablaufs aufgerufen wurde.
4. Prüfen Sie einzelne Protokolle. Jede Zeile stellt einen API-Connector dar, der versucht, während eines Benutzerablaufs aufgerufen zu werden. Wenn ein API-Aufruf fehlschlägt und ein Wiederholungsversuch durchgeführt wird, wird er weiterhin als einzelne Zeile dargestellt. Dies numberOfAttempts gibt an, wie oft Ihre API aufgerufen wurde. Dieser Wert kann sein 1oder 2. Weitere Informationen zum API-Aufruf finden Sie in den Protokollen.

• Erste Schritte mit unseren Beispielen.
• Sichern Sie Ihren API-Connector

Informationen zum Sichern Ihrer APIs finden Sie in den folgenden Artikeln:

• Exemplarische Vorgehensweise: Integrieren von REST-API-Anspruchsbörsen in Ihre Azure AD B2C-Benutzerreise als Orchestrierungsschritt
• Sichern Ihrer RESTful-API
• Referenz: RESTful Technical Profile