Lägga till en API-anslutningsapp i ett registreringsanvändarflöde

  • Artikel

Innan du börjar använder du väljaren Välj en principtyp för att välja den typ av princip som du konfigurerar. Azure Active Directory B2C erbjuder två metoder för att definiera hur användare interagerar med dina program: via fördefinierade användarflöden eller genom fullständigt konfigurerbara anpassade principer. De steg som krävs i den här artikeln skiljer sig åt för varje metod.

Som utvecklare eller IT-administratör kan du använda API-anslutningsappar för att integrera dina registreringsanvändarflöden med REST-API:er för att anpassa registreringsupplevelsen och integrera med externa system. I slutet av den här genomgången kan du skapa ett Azure AD B2C-användarflöde som interagerar med REST API-tjänster för att ändra dina registreringsupplevelser.

Du kan skapa en API-slutpunkt med något av våra exempel.

I det här scenariot lägger vi till möjligheten för användare att ange ett lojalitetsnummer på registreringssidan för Azure AD B2C. REST-API:et verifierar om kombinationen av e-post och lojalitetsnummer mappas till en kampanjkod. Om REST-API:et hittar en kampanjkod för den här användaren returneras den till Azure AD B2C. Slutligen infogas kampanjkoden i tokenanspråken som programmet ska använda.

Du kan också utforma interaktionen som ett orkestreringssteg. Detta är lämpligt när REST-API:et inte verifierar data på skärmen och alltid returnerar anspråk. Mer information finns i Genomgång: Integrera REST API-anspråksutbyten i din Azure AD B2C-användarresa som ett orkestreringssteg.

Förutsättningar

Skapa en API-anslutningsapp

Om du vill använda en API-anslutningsapp skapar du först API-anslutningsappen och aktiverar den sedan i ett användarflöde.

  1. Logga in på Azure-portalen.

  2. Under Azure-tjänster väljer du Azure AD B2C.

  3. Välj API-anslutningsappar och välj sedan Ny API-anslutningsapp.

    Screenshot of basic configuration for an API connector

  4. Ange ett visningsnamn för samtalet. Till exempel Verifiera användarinformation.

  5. Ange slutpunkts-URL :en för API-anropet.

  6. Välj typ av autentisering och konfigurera autentiseringsinformationen för att anropa ditt API. Lär dig hur du skyddar ditt API-Anslut eller.

    Screenshot of authentication configuration for an API connector

  7. Välj Spara.

Begäran som skickas till ditt API

En API-anslutningsapp materialiseras som en HTTP POST-begäran och skickar användarattribut ("anspråk") som nyckel/värde-par i en JSON-brödtext. Attribut serialiseras på samma sätt som Microsoft Graph-användaregenskaper .

Exempelbegäran

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "objectId": "11111111-0000-0000-0000-000000000000",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "<step-name>",
 "client_id":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

Endast användaregenskaper och anpassade attribut som anges i azure AD B2C-användarattributen> kan skickas i begäran.

Anpassade attribut finns i formatet extension_<extensions-app-id>_CustomAttribute i katalogen. Ditt API bör förvänta sig att ta emot anspråk i samma serialiserade format. Mer information om anpassade attribut finns i Definiera anpassade attribut i Azure AD B2C.

Dessutom skickas dessa anspråk vanligtvis i alla begäranden:

  • Nationella användargränssnitt ("ui_locales") – En slutanvändares nationella inställningar som konfigurerats på deras enhet. Detta kan användas av ditt API för att returnera internationaliserade svar.
  • Steg ('steg') – Steget eller punkten i användarflödet som API-anslutningsappen anropades för. Värden är:
    • PostFederationSignup - motsvarar "Efter federering med en identitetsprovider under registreringen"
    • PostAttributeCollection – motsvarar "Innan du skapar användaren"
    • PreTokenIssuance - motsvarar "Innan du skickar token (förhandsversion)". Läs mer om det här steget
  • Klient-ID ("client_id") – värdet appId för det program som en slutanvändare autentiserar till i ett användarflöde. Det här är inte resursprogrammets appId i åtkomsttoken.
  • E-postadress ("e-post") eller identiteter ("identiteter") – dessa anspråk kan användas av ditt API för att identifiera slutanvändaren som autentiserar till programmet.

Viktigt!

Om ett anspråk inte har något värde när API-slutpunkten anropas skickas inte anspråket till API:et. DITT API bör utformas för att uttryckligen kontrollera och hantera det fall där ett anspråk inte finns i begäran.

Aktivera API-anslutningsappen i ett användarflöde

Följ de här stegen för att lägga till en API-anslutningsapp i ett registreringsanvändarflöde.

  1. Logga in på Azure-portalen.

  2. Under Azure-tjänster väljer du Azure AD B2C.

  3. Välj Användarflöden och välj sedan det användarflöde som du vill lägga till API-anslutningsappen i.

  4. Välj API-anslutningsappar och välj sedan de API-slutpunkter som du vill anropa i följande steg i användarflödet:

    • Efter federering med en identitetsprovider under registreringen
    • Innan du skapar användaren
    • Innan du skickar token (förhandsversion)

    Selecting an API connector for a step in the user flow

  5. Välj Spara.

De här stegen finns bara för Registrering och inloggning (rekommenderas) och Registrera dig (rekommenderas) men gäller bara för registreringsdelen av upplevelsen.

Efter federering med en identitetsprovider under registreringen

En API-anslutningsapp i det här steget i registreringsprocessen anropas omedelbart efter att användaren autentiserats med en identitetsprovider (till exempel Google, Facebook och Microsoft Entra ID). Det här steget föregår sidan för attributsamlingen, som är det formulär som visas för användaren för att samla in användarattribut. Det här steget anropas inte om en användare registrerar sig med ett lokalt konto.

Exempelbegäran som skickas till API:et i det här steget

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [ 
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "step": "PostFederationSignup",
 "client_id":"<guid>",
 "ui_locales":"en-US"
}

De exakta anspråk som skickas till API:et beror på vilken information som tillhandahålls av identitetsprovidern. "e-post" skickas alltid.

Förväntade svarstyper från webb-API:et i det här steget

När webb-API:et tar emot en HTTP-begäran från Microsoft Entra-ID under ett användarflöde kan det returnera följande svar:

  • Fortsättningssvar
  • Blockerande svar

Fortsättningssvar

Ett fortsättningssvar anger att användarflödet ska fortsätta till nästa steg: sidan för attributsamlingen.

I ett fortsättningssvar kan API:et returnera anspråk. Om ett anspråk returneras av API:et gör anspråket följande:

  • I förväg fylls indatafältet på sidan för attributsamlingen.

Se ett exempel på ett fortsättningssvar.

Blockerande svar

Ett blockerande svar avslutar användarflödet. Det kan utfärdas avsiktligt av API:et för att stoppa fortsättningen av användarflödet genom att visa en blocksida för användaren. På blocksidan visas den userMessage som tillhandahålls av API:et.

Se ett exempel på ett blockerande svar.

Innan du skapar användaren

En API-anslutningsapp i det här steget i registreringsprocessen anropas efter sidan för attributsamlingen, om en är inkluderad. Det här steget anropas alltid innan ett användarkonto skapas.

Exempelbegäran som skickas till API:et i det här steget

POST <API-endpoint>
Content-type: application/json

{
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "givenName":"John",
 "surname":"Smith",
 "jobTitle":"Supplier",
 "streetAddress":"1000 Microsoft Way",
 "city":"Seattle",
 "postalCode": "12345",
 "state":"Washington",
 "country":"United States",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
 "step": "PostAttributeCollection",
 "client_id":"93fd07aa-333c-409d-955d-96008fd08dd9",
 "ui_locales":"en-US"
}

De anspråk som skickas till API:et är beroende av att informationen samlas in från användaren eller tillhandahålls av identitetsprovidern.

Förväntade svarstyper från webb-API:et i det här steget

När webb-API:et tar emot en HTTP-begäran från Microsoft Entra-ID under ett användarflöde kan det returnera följande svar:

  • Fortsättningssvar
  • Blockerande svar
  • Valideringssvar

Fortsättningssvar

Ett fortsättningssvar anger att användarflödet ska fortsätta till nästa steg: skapa användaren i katalogen.

I ett fortsättningssvar kan API:et returnera anspråk. Om ett anspråk returneras av API:et gör anspråket följande:

  • Åsidosätter alla värden som redan har angetts av en användare på sidan för attributsamlingen.

Om du vill skriva anspråk till katalogen vid registrering som inte ska samlas in från användaren bör du fortfarande välja anspråken under Användarattribut för användarflödet, vilket som standard ber användaren om värden, men du kan använda anpassad JavaScript eller CSS för att dölja indatafälten från en slutanvändare.

Se ett exempel på ett fortsättningssvar.

Blockerande svar

Ett blockerande svar avslutar användarflödet. Det kan utfärdas avsiktligt av API:et för att stoppa fortsättningen av användarflödet genom att visa en blocksida för användaren. På blocksidan visas den userMessage som tillhandahålls av API:et.

Se ett exempel på ett blockerande svar.

Svar på valideringsfel

När API:et svarar med ett svar på valideringsfel finns användarflödet kvar på sidan för attributsamlingen och ett userMessage visas för användaren. Användaren kan sedan redigera och skicka formuläret igen. Den här typen av svar kan användas för indataverifiering.

Se ett exempel på ett svar på valideringsfel.

Innan du skickar token (förhandsversion)

Viktigt!

API-anslutningsappar som används i det här steget är i förhandsversion. Mer information om förhandsversioner finns i Produktvillkor för onlinetjänster.

En API-anslutningsapp i det här steget anropas när en token ska utfärdas under inloggningar och registreringar. En API-anslutningsapp för det här steget kan användas för att utöka token med anspråksvärden från externa källor.

Exempelbegäran som skickas till API:et i det här steget

POST <API-endpoint>
Content-type: application/json

{
 "clientId": "231c70e8-8424-48ac-9b5d-5623b9e4ccf3",
 "step": "PreTokenApplicationClaims",
 "ui_locales":"en-US",
 "email": "johnsmith@fabrikam.onmicrosoft.com",
 "identities": [
     {
     "signInType":"federated",
     "issuer":"facebook.com",
     "issuerAssignedId":"0123456789"
     }
 ],
 "displayName": "John Smith",
 "extension_<extensions-app-id>_CustomAttribute1": "custom attribute value",
 "extension_<extensions-app-id>_CustomAttribute2": "custom attribute value",
}

De anspråk som skickas till API:et beror på den information som definierats för användaren.

Förväntade svarstyper från webb-API:et i det här steget

När webb-API:et tar emot en HTTP-begäran från Microsoft Entra-ID under ett användarflöde kan det returnera följande svar:

  • Fortsättningssvar

Fortsättningssvar

Ett fortsättningssvar anger att användarflödet ska fortsätta till nästa steg: utfärda token.

I ett fortsättningssvar kan API:et returnera ytterligare anspråk. Ett anspråk som returneras av API:et som du vill returnera i token måste vara ett inbyggt anspråk eller definierat som ett anpassat attribut och måste väljas i programanspråkkonfigurationen för användarflödet.

Anspråksvärdet i token är det värde som returneras av API:et, inte värdet i katalogen. Vissa anspråksvärden kan inte skrivas över av API-svaret. Anspråk som kan returneras av API:et motsvarar uppsättningen som finns under Användarattribut med undantag för email.

Se ett exempel på ett fortsättningssvar.

Kommentar

API:et anropas endast under en första autentisering. När du använder uppdateringstoken för att tyst få ny åtkomst eller ID-token innehåller token de värden som utvärderas under den första autentiseringen.

Exempelsvar

Exempel på ett fortsättningssvar

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
}
Parameter Type Obligatoriskt Beskrivning
version Sträng Ja Versionen av api:et.
åtgärd Sträng Ja Värdet måste vara Continue.
<builtInUserAttribute> <attributtyp> Inga Returnerade värden kan skriva över värden som samlats in från en användare.
<extension_{extensions-app-id}_CustomAttribute> <attributtyp> Inga Anspråket behöver inte innehålla _<extensions-app-id>_, det är valfritt. Returnerade värden kan skriva över värden som samlats in från en användare.

Exempel på ett blockeringssvar

HTTP/1.1 200 OK
Content-type: application/json

{
    "version": "1.0.0",
    "action": "ShowBlockPage",
    "userMessage": "There was a problem with your request. You are not able to sign up at this time. Please contact your system administrator",
}
Parameter Type Obligatoriskt Beskrivning
version Sträng Ja Versionen av api:et.
åtgärd Sträng Ja Värdet måste vara ShowBlockPage
userMessage Sträng Ja Meddelande som ska visas för användaren.

Slutanvändarupplevelse med ett blockerande svar

Example of a blocking response

Exempel på ett svar på valideringsfel

HTTP/1.1 400 Bad Request
Content-type: application/json

{
    "version": "1.0.0",
    "status": 400,
    "action": "ValidationError",
    "userMessage": "Please enter a valid Postal Code."
}
Parameter Type Obligatoriskt Beskrivning
version Sträng Ja Versionen av api:et.
åtgärd Sträng Ja Värdet måste vara ValidationError.
status Heltal/sträng Ja Måste vara värdet 400, eller "400" för ett ValidationError-svar.
userMessage Sträng Ja Meddelande som ska visas för användaren.

Kommentar

HTTP-statuskoden måste vara "400" utöver värdet "status" i svarets brödtext.

Slutanvändarupplevelse med svar på valideringsfel

Example of a validation-error response

Förbereda en REST API-slutpunkt

För den här genomgången bör du ha ett REST-API som verifierar om en e-postadress är registrerad i serverdelssystemet med ett lojalitets-ID. Om det är registrerat bör REST-API:et returnera en registreringsbefordranskod som kunden kan använda för att köpa varor i ditt program. Annars bör REST-API:et returnera ett HTTP 409-felmeddelande: "Lojalitets-ID {lojalitets-ID} är inte associerat med e-postadressen {email}.".

Följande JSON-kod illustrerar de data som Azure AD B2C skickar till REST API-slutpunkten.

{
    "email": "User email address",
    "language": "Current UI language",
    "loyaltyId": "User loyalty ID"
}

När rest-API:et verifierar data måste det returnera en HTTP 200 (Ok) med följande JSON-data:

{
    "promoCode": "24534"
}

Om verifieringen misslyckades måste REST-API:et returnera en HTTP 409 (konflikt) med userMessage JSON-elementet. IEF förväntar sig det userMessage anspråk som REST-API:et returnerar. Det här anspråket visas som en sträng för användaren om verifieringen misslyckas.

{
    "version": "1.0.1",
    "status": 409,
    "userMessage": "LoyaltyId ID '1234' is not associated with 'david@contoso.com' email address."
}

Installationen av REST API-slutpunkten ligger utanför omfånget för den här artikeln. Vi har skapat ett Azure Functions-exempel . Du kan komma åt den fullständiga Azure-funktionskoden på GitHub.

Definiera anspråk

Ett anspråk ger tillfällig lagring av data under en Azure AD B2C-principkörning. Du kan deklarera anspråk i avsnittet anspråksschema .

  1. Öppna tilläggsfilen för principen. Exempel: SocialAndLocalAccounts/TrustFrameworkExtensions.xml
  2. Sök efter elementet BuildingBlocks . Om elementet inte finns lägger du till det.
  3. Leta upp elementet ClaimsSchema . Om elementet inte finns lägger du till det.
  4. Lägg till följande anspråk i elementet ClaimsSchema .
<ClaimType Id="loyaltyId">
  <DisplayName>Your loyalty ID</DisplayName>
  <DataType>string</DataType>
  <UserInputType>TextBox</UserInputType>
</ClaimType>
<ClaimType Id="promoCode">
  <DisplayName>Your promo code</DisplayName>
  <DataType>string</DataType>
  <UserInputType>Paragraph</UserInputType>
</ClaimType>
  <ClaimType Id="userLanguage">
  <DisplayName>User UI language (used by REST API to return localized error messages)</DisplayName>
  <DataType>string</DataType>
</ClaimType>

Lägga till den tekniska profilen för RESTful API

En vilsam teknisk profil ger stöd för att interagera med din egen RESTful-tjänst. Azure AD B2C skickar data till RESTful-tjänsten i en InputClaims samling och tar emot data tillbaka i en OutputClaims samling. Leta upp elementet ClaimsProviders och lägg till en ny anspråksprovider på följande sätt:

<ClaimsProvider>
  <DisplayName>REST APIs</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="REST-ValidateProfile">
      <DisplayName>Check loyaltyId 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/ValidateProfile?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="loyaltyId" />
        <InputClaim ClaimTypeReferenceId="email" />
        <InputClaim ClaimTypeReferenceId="userLanguage" PartnerClaimType="lang" DefaultValue="{Culture:LCID}" AlwaysUseDefaultValue="true" />
      </InputClaims>
      <OutputClaims>
        <!-- Claims parsed from your REST API -->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop" />
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

I det här exemplet userLanguage skickas till REST-tjänsten som lang i JSON-nyttolasten. Värdet för anspråket userLanguage innehåller det aktuella användarspråks-ID:t. Mer information finns i anspråkslösare.

Konfigurera den tekniska profilen för RESTful API

När du har distribuerat rest-API:et anger du metadata för den tekniska profilen så att de REST-ValidateProfile återspeglar ditt eget REST-API, inklusive:

  • ServiceUrl. Ange URL:en för REST API-slutpunkten.
  • SendClaimsIn. Ange hur indataanspråken skickas till RESTful-anspråksprovidern.
  • AuthenticationType. Ange vilken typ av autentisering som utförs av RESTful-anspråksprovidern.
  • AllowInsecureAuthInProduction. I en produktionsmiljö måste du ange dessa metadata till true

Mer konfiguration finns i RESTfuls tekniska profilmetadata .

Kommentarerna ovan AuthenticationType och AllowInsecureAuthInProduction ange ändringar som du bör göra när du flyttar till en produktionsmiljö. Information om hur du skyddar dina RESTful-API:er för produktion finns i Skydda RESTful API.

Verifiera användarens indata

För att få användarens lojalitetsnummer under registreringen måste du tillåta att användaren anger dessa data på skärmen. Lägg till utdataanspråket loyaltyId på registreringssidan genom att lägga till det i det befintliga registreringsavsnittets OutputClaims element för teknisk profil. Ange hela listan med utdataanspråk för att styra ordningen som anspråken visas på skärmen.

Lägg till referensen för den tekniska verifieringsprofilen till den tekniska registreringsprofilen, som anropar REST-ValidateProfile. Den nya tekniska verifieringsprofilen läggs till överst i samlingen <ValidationTechnicalProfiles> som definieras i basprincipen. Det här beteendet innebär att Azure AD B2C först efter valideringen går vidare för att skapa kontot i katalogen.

  1. Hitta elementet ClaimsProviders . Lägg till en ny anspråksprovider på följande sätt:

    <ClaimsProvider>
  <DisplayName>Local Account</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="LocalAccountSignUpWithLogonEmail">
      <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="Verified.Email" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="newPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="reenterPassword" Required="true"/>
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surName"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile" />
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>
<ClaimsProvider>
  <DisplayName>Self Asserted</DisplayName>
  <TechnicalProfiles>
    <TechnicalProfile Id="SelfAsserted-Social">
      <InputClaims>
        <InputClaim ClaimTypeReferenceId="email" />
      </InputClaims>
        <OutputClaims>
        <OutputClaim ClaimTypeReferenceId="email" />
        <OutputClaim ClaimTypeReferenceId="displayName"/>
        <OutputClaim ClaimTypeReferenceId="givenName"/>
        <OutputClaim ClaimTypeReferenceId="surname"/>
        <!-- Required to present the text box to collect the data from the user -->
        <OutputClaim ClaimTypeReferenceId="loyaltyId"/>
        <!-- Required to pass the promoCode returned from "REST-ValidateProfile" 
        to subsequent orchestration steps and token issuance-->
        <OutputClaim ClaimTypeReferenceId="promoCode" />
      </OutputClaims>
      <ValidationTechnicalProfiles>
        <ValidationTechnicalProfile ReferenceId="REST-ValidateProfile"/>
      </ValidationTechnicalProfiles>
    </TechnicalProfile>
  </TechnicalProfiles>
</ClaimsProvider>

Inkludera ett anspråk i token

Om du vill returnera kampanjkodsanspråket tillbaka till det förlitande partprogrammet lägger du till ett utdataanspråk i SocialAndLocalAccounts/SignUpOrSignIn.xml filen. Utdataanspråket gör att anspråket kan läggas till i token efter en lyckad användarresa och skickas till programmet. Ändra det tekniska profilelementet i avsnittet förlitande part för att lägga promoCode till som ett utdataanspråk.

<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="promoCode" DefaultValue="" />
    </OutputClaims>
    <SubjectNamingInfo ClaimType="sub" />
  </TechnicalProfile>
</RelyingParty>

Testa den anpassade principen

  1. Logga in på Azure-portalen.
  2. Om du har åtkomst till flera klienter väljer du ikonen Inställningar på den översta menyn för att växla till din Microsoft Entra-ID-klient från menyn Kataloger + prenumerationer.
  3. Välj Alla tjänster i det övre vänstra hörnet i Azure-portalen och sök sedan efter och välj Appregistreringar.
  4. Välj Identity Experience Framework.
  5. Välj Överför anpassad princip och ladda sedan upp de principfiler som du har ändrat: TrustFrameworkExtensions.xml och SignUpOrSignin.xml.
  6. Välj den registrerings- eller inloggningsprincip som du laddade upp och klicka på knappen Kör nu .
  7. Du bör kunna registrera dig med hjälp av en e-postadress.
  8. Klicka på länken Registrera dig nu .
  9. I ditt lojalitets-ID skriver du 1234 och klickar på Fortsätt. Nu bör du få ett verifieringsfelmeddelande.
  10. Ändra till ett annat värde och klicka på Fortsätt.
  11. Token som skickas tillbaka till ditt program innehåller anspråket promoCode .
{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/f06c2fe8-709f-4030-85dc-38a4bfd9e82d/v2.0/",
  "aud": "e1d2612f-c2bc-4599-8e7b-d874eaca1ee1",
  "acr": "b2c_1a_signup_signin",
  "nonce": "defaultNonce",
  "iat": 1584292103,
  "auth_time": 1584292103,
  "name": "Emily Smith",
  "email": "emily@outlook.com",
  "given_name": "Emily",
  "family_name": "Smith",
  "promoCode": "84362"
  ...
}

Metodtips och hur du felsöker

Använda serverlösa molnfunktioner

Serverlösa funktioner, till exempel HTTP-utlösare i Azure Functions, tillhandahåller ett sätt att skapa API-slutpunkter att använda med API-anslutningsappen. Du kan använda den serverlösa molnfunktionen för att till exempel utföra valideringslogik och begränsa registreringar till specifika e-postdomäner. Den serverlösa molnfunktionen kan också anropa och anropa andra webb-API:er, datalager och andra molntjänster för komplexa scenarier.

Metodtips

Se till att du har gjort följande:

  • Ditt API följer API-begärande- och svarskontrakten enligt beskrivningen ovan.
  • Slutpunkts-URL:en för API-anslutningsappen pekar på rätt API-slutpunkt.
  • Api:et söker uttryckligen efter nullvärden för mottagna anspråk som det är beroende av.
  • Ditt API implementerar en autentiseringsmetod som beskrivs i skydda din API-Anslut eller.
  • Ditt API svarar så snabbt som möjligt för att säkerställa en smidig användarupplevelse.
    • Azure AD B2C väntar i högst 20 sekunder för att få ett svar. Om ingen tas emot görs ytterligare ett försök (försök igen) att anropa ditt API.
    • Om du använder en serverlös funktion eller skalbar webbtjänst använder du en värdplan som håller API:et "vaken" eller "varmt" i produktion. För Azure Functions rekommenderar vi att du åtminstone använder Premium-planen i produktion.
  • Säkerställ hög tillgänglighet för ditt API.
  • Övervaka och optimera prestanda för underordnade API:er, databaser eller andra beroenden för ditt API.

Viktigt!

Dina slutpunkter måste uppfylla säkerhetskraven för Azure AD B2C. Äldre TLS-versioner och chiffer är inaktuella. Mer information finns i Azure AD B2C TLS- och chiffersvitkrav.

Använda loggning

I allmänhet är det bra att använda loggningsverktygen som aktiveras av webb-API-tjänsten, till exempel Application Insights, för att övervaka ditt API för oväntade felkoder, undantag och dåliga prestanda.

  • Övervaka för HTTP-statuskoder som inte är HTTP 200 eller 400.
  • En HTTP-statuskod på 401 eller 403 indikerar vanligtvis att det finns ett problem med din autentisering. Dubbelkolla API:ets autentiseringslager och motsvarande konfiguration i API-anslutningsappen.
  • Använd mer aggressiva loggningsnivåer (till exempel "spårning" eller "felsökning") under utveckling om det behövs.
  • Övervaka ditt API för långa svarstider.

Dessutom loggar Azure AD B2C metadata om DE API-transaktioner som sker under användarautentiseringar via ett användarflöde. Så här hittar du följande:

  1. Gå till Azure AD B2C.
  2. Under Aktiviteter väljer du Granskningsloggar.
  3. Filtrera listvyn: För Datum väljer du önskat tidsintervall och för Aktivitet väljer du Ett API anropades som en del av ett användarflöde.
  4. Granska enskilda loggar. Varje rad representerar en API-anslutningsapp som försöker anropas under ett användarflöde. Om ett API-anrop misslyckas och ett nytt försök görs representeras det fortfarande som en enda rad. numberOfAttempts Anger hur många gånger api:et anropades. Det här värdet kan vara 1eller 2. Annan information om API-anropet beskrivs i loggarna.

Example of an API connector transaction during user authentication

Använda serverlösa molnfunktioner

Serverlösa molnfunktioner, till exempel HTTP-utlösare i Azure Functions, ger ett enkelt, högtillgängligt och högpresterande sätt att skapa API-slutpunkter som ska användas som API-anslutningsappar.

Metodtips

Se till att du har gjort följande:

  • Api:et söker uttryckligen efter nullvärden för mottagna anspråk som det är beroende av.
  • Ditt API implementerar en autentiseringsmetod som beskrivs i skydda din API-Anslut eller.
  • Ditt API svarar så snabbt som möjligt för att säkerställa en smidig användarupplevelse.
    • Om du använder en serverlös funktion eller skalbar webbtjänst använder du en värdplan som håller API:et "vaken" eller "varmt" i produktion. För Azure Functions rekommenderar vi att du åtminstone använder Premium-planen
  • Säkerställ hög tillgänglighet för ditt API.
  • Övervaka och optimera prestanda för underordnade API:er, databaser eller andra beroenden för ditt API.

Viktigt!

Dina slutpunkter måste uppfylla säkerhetskraven för Azure AD B2C. Äldre TLS-versioner och chiffer är inaktuella. Mer information finns i Azure AD B2C TLS- och chiffersvitkrav.

Använda loggning

I allmänhet är det bra att använda loggningsverktygen som aktiveras av webb-API-tjänsten, till exempel Application Insights, för att övervaka ditt API för oväntade felkoder, undantag och dåliga prestanda.

  • Övervaka för HTTP-statuskoder som inte är HTTP 200 eller 400.
  • En HTTP-statuskod på 401 eller 403 indikerar vanligtvis att det finns ett problem med din autentisering. Dubbelkolla API:ets autentiseringslager och motsvarande konfiguration i API-anslutningsappen.
  • Använd mer aggressiva loggningsnivåer (till exempel "spårning" eller "felsökning") under utveckling om det behövs.
  • Övervaka ditt API för långa svarstider.

Nästa steg