Přidání konektorů rozhraní API pro registraci toků uživatelů

Důležité

Od 1. května 2025 už nebude Azure AD B2C k dispozici k nákupu pro nové zákazníky. Další informace najdete v našich nejčastějších dotazech.

Než začnete, pomocí selektoru Zvolit typ zásady v horní části této stránky zvolte typ zásady, kterou nastavujete. Azure Active Directory B2C nabízí dvě metody pro definování způsobu interakce uživatelů s vašimi aplikacemi: prostřednictvím předdefinovaných toků uživatelů nebo prostřednictvím plně konfigurovatelných vlastních zásad. Kroky vyžadované v tomto článku se pro každou metodu liší.

Jako vývojář nebo správce IT můžete pomocí konektorů rozhraní API integrovat toky uživatelů registrace s rozhraními REST API, abyste přizpůsobili prostředí registrace a integrovali se s externími systémy. Na konci tohoto názorného postupu budete moct vytvořit tok uživatelů Azure AD B2C, který komunikuje se službami REST API za účelem úpravy prostředí registrace.

Pomocí jedné z našich ukázek můžete vytvořit koncový bod rozhraní API.

V tomto scénáři přidáme možnost, aby uživatelé zadali číslo věrnosti na registrační stránku Azure AD B2C. Rozhraní REST API ověřuje, jestli je kombinace e-mailu a čísla věrnosti namapovaná na propagační kód. Pokud rozhraní REST API najde propagační kód pro tohoto uživatele, vrátí se do Azure AD B2C. Nakonec se propagační kód vloží do deklarací tokenů, které aplikace bude využívat.

Interakci můžete také navrhnout jako krok orchestrace. To je vhodné, když rozhraní REST API nebude ověřovat data na obrazovce a vždy vracet deklarace identity. Další informace najdete v tématu Návod: Integrace výměn deklarací identity rest API ve vaší cestě uživatele Azure AD B2C jako krok orchestrace.

Požadavky

Vytvořte tok uživatele, aby se uživatelé mohli zaregistrovat a přihlásit k vaší aplikaci.
Zaregistrujte webovou aplikaci.

Dokončete kroky v Začněte s vlastními zásadami ve službě Azure Active Directory B2C. V tomto kurzu se dozvíte, jak aktualizovat soubory vlastních zásad tak, aby používaly konfiguraci tenanta Azure AD B2C.
Zaregistrujte webovou aplikaci.

Vytvoření konektoru rozhraní API

Pokud chcete použít konektor rozhraní API, nejprve vytvoříte konektor rozhraní API a pak ho povolíte v toku uživatele.

Přihlaste se do Azure Portalu.
V části Služby Azure vyberte Azure AD B2C.
Vyberte konektory rozhraní API a pak vyberte Nový konektor rozhraní API.
Zadejte zobrazovaný název hovoru. Můžete například ověřit informace o uživateli.
Zadejte adresu URL koncového bodu pro volání rozhraní API.
Zvolte typ ověřování a nakonfigurujte ověřovací informace pro volání rozhraní API. Zjistěte, jak zabezpečit konektor ROZHRANÍ API.
Vyberte Uložit.

Požadavek odeslaný do vašeho rozhraní API

Konektor rozhraní API se materializuje jako požadavek HTTP POST a odesílá atributy uživatele ('claims') jako páry klíč-hodnota v těle JSON. Atributy jsou serializovány podobně jako vlastnosti uživatele Microsoft Graphu .

Příklad požadavku

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",
 "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":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

V požadavku se dají odesílat pouze vlastnosti uživatelů a vlastní atributy uvedené v Azure AD B2C>atributech uživatelů.

Vlastní atributy existují ve formátu extension_<extensions-app-id>_CustomAttribute v adresáři. Vaše rozhraní API by mělo očekávat příjem deklarací identity ve stejném serializovaném formátu. Další informace o vlastních atributech najdete v tématu Definování vlastních atributů v Azure AD B2C.

Kromě toho se tyto deklarace identity obvykle posílají ve všech požadavcích:

Národní prostředí uživatelského rozhraní (ui_locales) – národní prostředí koncového uživatele nakonfigurované na svém zařízení. Vaše rozhraní API může použít k vrácení internacionalizovaných odpovědí.
Krok (krok) – krok nebo bod v toku uživatele, pro který byl konektor rozhraní API vyvolán. Mezi hodnoty patří:
- PostFederationSignup – odpovídá po federaci se zprostředkovatelem identity během registrace.
- PostAttributeCollection – odpovídá "Před vytvořením uživatele"
- PreTokenIssuance – odpovídá "Před odesláním tokenu (Preview)". Další informace o tomto kroku
ID klienta (client_id) – appId hodnota aplikace, pro kterou se koncový uživatel ověřuje v toku uživatele. Toto není aplikace appId prostředků v přístupových tokenech.
E-mailová adresa ('email') nebo identity ('identity') – tyto deklarace může vaše API použít k identifikaci uživatele, který se ověřuje v aplikaci.

Důležité

Pokud deklarace identity nemá v době volání koncového bodu rozhraní API hodnotu, deklarace identity se do rozhraní API neodesílají. Vaše rozhraní API by mělo být navrženo tak, aby explicitně kontrolovalo a zpracovávalo případ, kdy nárok není v požadavku.

Povolení konektoru rozhraní API v uživatelském toku

Pokud chcete přidat konektor rozhraní API do toku registrace uživatele, postupujte podle těchto kroků.

Přihlaste se do Azure Portalu.
V části Služby Azure vyberte Azure AD B2C.
Vyberte Toky uživatelů a poté vyberte tok uživatele, do kterého chcete přidat konektor rozhraní API.
Vyberte konektory rozhraní API a pak vyberte koncové body rozhraní API, které chcete vyvolat v následujícím postupu v toku uživatele:
- Po propojení s poskytovatelem identity během registrace
- Před vytvořením uživatele
- Před odesláním tokenu (Preview)
Vyberte Uložit.

Tyto kroky existují jenom pro registraci a přihlášení (doporučeno) a registraci (doporučeno), ale platí jenom pro registraci.

Konektor rozhraní API v tomto kroku v procesu registrace se vyvolá okamžitě po ověření uživatele u zprostředkovatele identity (jako je Google, Facebook a Microsoft Entra ID). Tento krok předchází stránce pro sběr atributů, což je formulář, který se uživateli zobrazuje pro sběr uživatelských atributů. Tento krok se nevyvolá, pokud se uživatel registruje k místnímu účtu.

Příklad požadavku odeslaného do rozhraní API v tomto kroku

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

Přesné deklarace identity odeslané do rozhraní API závisí na informacích, které poskytuje zprostředkovatel identity. E-mail je vždy posílán.

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Když webové rozhraní API obdrží požadavek HTTP z ID Microsoft Entra během toku uživatele, může vrátit tyto odpovědi:

Odpověď na pokračování
Blokující odpověď

Odpověď na pokračování

Pokračování v odpovědi znamená, že by měl uživatelský proces pokračovat dalším krokem: na stránku pro sběr atributů.

V odpovědi na pokračování může rozhraní API vracet deklarace identity. Pokud rozhraní API vrátí nárok, provede nárok následující:

Předvyplní vstupní pole na stránce kolekce atributů.

Podívejte se na příklad reakce na pokračování.

Blokující odpověď

Blokující odpověď ukončí tok uživatele. Rozhraní API může být záměrně využito k zastavení pokračování uživatelského toku zobrazením blokovací stránky uživateli. Stránka bloku zobrazuje informace poskytnuté rozhraním API.

Podívejte se na příklad blokující odpovědi.

Před vytvořením uživatele

Konektor rozhraní API v tomto kroku přihlašovacího procesu se vyvolá po sběru atributů, pokud je to součástí tohoto procesu. Tento krok se vždy vyvolá před vytvořením uživatelského účtu.

Příklad požadavku odeslaného do rozhraní API v tomto kroku

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":"00001111-aaaa-2222-bbbb-3333cccc4444",
 "ui_locales":"en-US"
}

Deklarace identity, které se odesílají do rozhraní API, závisí na informacích, které uživatel shromažďuje, nebo je poskytuje zprostředkovatel identity.

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Když webové rozhraní API obdrží požadavek HTTP z ID Microsoft Entra během toku uživatele, může vrátit tyto odpovědi:

Odpověď na pokračování
Blokující odpověď
Odpověď na ověření

Odpověď na pokračování

Odpověď o pokračování naznačuje, že uživatelský tok by měl pokračovat k dalšímu kroku: vytvořit uživatele v adresáři.

V odpovědi na pokračování může rozhraní API vracet deklarace identity. Pokud rozhraní API vrátí nárok, provede nárok následující:

Přepíše všechny hodnoty, které již uživatel zadal na stránce kolekce atributů.

Pokud chcete zapsat nároky do adresáře při registraci, které by neměly být shromažďovány od uživatele, měli byste stále vybrat nároky v rámci atributů uživatele toku uživatele, který ve výchozím nastavení vyžaduje zadání hodnot od uživatele, ale můžete použít vlastní JavaScript nebo CSS pro skrytí vstupních polí před koncovým uživatelem.

Podívejte se na příklad reakce na pokračování.

Blokující odpověď

Podívejte se na příklad blokující odpovědi.

Odpověď na chybu ověření

Když rozhraní API odpoví chybovou odpovědí ověření, tok uživatele zůstane na stránce kolekce atributů a userMessage se uživateli zobrazí. Uživatel pak může formulář upravit a znovu odeslat. Tento typ odpovědi lze použít pro ověření vstupu.

Podívejte se na příklad odpovědi na chybu ověřování.

Před odesláním tokenu (Preview)

Důležité

Konektory rozhraní API použité v tomto kroku jsou ve verzi Preview. Další informace o verzích Preview najdete v části Podmínky produktu pro online služby.

Konektor rozhraní API v tomto kroku se vyvolá, když má být token vydán během přihlašování a registrace. Konektor rozhraní API pro tento krok lze použít k obohacení tokenu o hodnoty deklarací identity z externích zdrojů.

Příklad požadavku odeslaného do rozhraní API v tomto kroku

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

{
 "clientId": "11112222-bbbb-3333-cccc-4444dddd5555",
 "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",
}

Deklarace identity odeslané do rozhraní API závisí na informacích definovaných pro uživatele.

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Když webové rozhraní API obdrží požadavek HTTP z ID Microsoft Entra během toku uživatele, může vrátit tyto odpovědi:

Odpověď na pokračování

Odpověď na pokračování

Pokračující odpověď znamená, že uživatelský tok by měl pokračovat k dalšímu kroku: vydat token.

V pokračující odpovědi může rozhraní API vrátit další nároky. Deklarace identity vrácená rozhraním API, které chcete v tokenu vrátit, musí být předdefinovaná deklarace identity nebo definovaná jako vlastní atribut a musí být vybrána v konfiguraci deklarací identity aplikace toku uživatele.

Hodnota claimu v tokenu bude hodnota vrácená rozhraním API, nikoli hodnota v adresáři. Některé hodnoty nároků nelze přepsat odpovědí rozhraní API. Nároky, které mohou být vráceny rozhraním API, odpovídají sadě nalezené v uživatelských atributů s výjimkou email.

Podívejte se na příklad reakce na pokračování.

Poznámka:

Rozhraní API je aktivováno pouze po úvodní autentizaci. Při použití obnovovacích tokenů k tichému získání nových přístupových tokenů nebo tokenů ID bude token obsahovat hodnoty vyhodnocené během počátečního ověřování.

Ukázkové odpovědi

Příklad odpovědi na pokračování

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
}

Parametr	Typ	Povinné	Popis
verze	Řetězec	Ano	Verze vašeho rozhraní API.
akce	Řetězec	Ano	Hodnota musí být `Continue`.
<vestavěnáUživatelskáAtributa>	<atribut-typ>	Ne	Vrácené hodnoty mohou přepsat hodnoty shromážděné od uživatele.
<extension_{extensions-app-id}_CustomAttribute>	<atribut-typ>	Ne	Nárok nemusí obsahovat `_<extensions-app-id>_`, je volitelný. Vrácené hodnoty mohou přepsat hodnoty shromážděné od uživatele.

Příklad blokující odpovědi

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",
}

Parametr	Typ	Povinné	Popis
verze	Řetězec	Ano	Verze vašeho rozhraní API.
akce	Řetězec	Ano	Hodnota musí být `ShowBlockPage`
uživatelská zpráva	Řetězec	Ano	Zpráva, která se zobrazí uživateli.

Prostředí koncového uživatele s blokující odpovědí

Příklad blokující odpovědi

Příklad odpovědi na chybu ověřování

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."
}

Parametr	Typ	Povinné	Popis
verze	Řetězec	Ano	Verze vašeho rozhraní API.
akce	Řetězec	Ano	Hodnota musí být `ValidationError`.
stav	Celé číslo / řetězec	Ano	Musí být hodnota `400`nebo `"400"` pro odpověď ValidationError.
uživatelská zpráva	Řetězec	Ano	Zpráva, která se zobrazí uživateli.

Poznámka:

Stavový kód HTTP musí být kromě hodnoty status v textu odpovědi 400.

Zkušenost koncového uživatele s odpovědí na ověřovací chybu

Příklad odpovědi na chybu ověřování

Příprava koncového bodu rozhraní REST API

Pro účely tohoto názorného postupu byste měli mít rozhraní REST API, které ověřuje, jestli je e-mailová adresa zaregistrovaná v back-endovém systému s id věrnosti. Pokud je zaregistrované, rozhraní REST API by mělo vrátit registrační propagační kód, který může zákazník použít k nákupu zboží v rámci vaší aplikace. V opačném případě by rozhraní REST API mělo vrátit chybovou zprávu HTTP 409: "Id věrnosti {id} není přidruženo k e-mailové adrese {email}".

Následující kód JSON znázorňuje data, která Azure AD B2C odešle do koncového bodu rozhraní REST API.

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

Jakmile rozhraní REST API ověří data, musí vrátit http 200 (OK) s následujícími daty JSON:

{
    "promoCode": "24534"
}

Pokud se ověření nezdařilo, musí rozhraní REST API vrátit http 409 (konflikt) s elementem userMessage JSON. IEF očekává userMessage deklaraci identity, kterou rozhraní REST API vrátí. Tato deklarace identity se uživateli zobrazí jako řetězec, pokud ověření selže.

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

Nastavení koncového bodu rozhraní REST API je mimo rozsah tohoto článku. Vytvořili jsme ukázku Azure Functions . Úplný kód funkce Azure můžete získat na GitHubu.

Definice nároků

Nárok poskytuje dočasné úložiště dat během provádění zásad Azure AD B2C. Můžete uvést nároky v rámci oddílu schématu nároků.

Otevřete soubor s rozšířeními zásad. Například: SocialAndLocalAccounts/TrustFrameworkExtensions.xml.
Vyhledejte prvek BuildingBlocks. Pokud prvek neexistuje, přidejte ho.
Vyhledejte prvek ClaimsSchema. Pokud prvek neexistuje, přidejte ho.
Do elementu ClaimsSchema přidejte následující claimy.

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

Přidání technického profilu rozhraní RESTful API

Technický profil RESTful poskytuje podporu pro propojení s vaší vlastní službou RESTful. Azure AD B2C odesílá data do služby RESTful v InputClaims kolekci a přijímá data zpět v OutputClaims kolekci. Vyhledejte element ClaimsProviders a přidejte nového zprostředkovatele deklarací následujícím způsobem:

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

V tomto příkladu bude userLanguage odesláno ke službě REST jako lang v datové části JSON. Hodnota userLanguage deklarace obsahuje aktuální ID jazyka uživatele. Další informace najdete v tématu řešitel nároků.

Konfigurace technického profilu rozhraní RESTful API

Po nasazení rozhraní REST API nastavte metadata technického REST-ValidateProfile profilu tak, aby odrážela vaše vlastní rozhraní REST API, včetně následujících:

Adresa URL služby. Nastavte adresu URL koncového bodu rozhraní REST API.
SendClaimsIn. Určete, jak se vstupní nároky odesílají zprostředkovateli nároků RESTful.
Typ ověřování. Nastavte typ ověřování, který je prováděn poskytovatelem prokazatelností pomocí RESTful rozhraní.
AllowInsecureAuthInProduction. V produkčním prostředí nezapomeňte tato metadata nastavit na true

Další konfigurace najdete v metadatech technického profilu RESTful .

Výše uvedené AuthenticationType komentáře a AllowInsecureAuthInProduction určují změny, které byste měli provést při přechodu do produkčního prostředí. Informace o zabezpečení rozhraní RESTful API pro produkční prostředí najdete v tématu Zabezpečené rozhraní RESTful API.

Ověření vstupu uživatele

Pokud chcete získat číslo věrnosti uživatele během registrace, musíte uživateli povolit zadat tato data na obrazovce. Přidejte výstupní nárok loyaltyId na registrační stránku přidáním do prvku OutputClaims v existující sekci technického profilu registrace. Zadejte celý seznam výstupních deklarací identity pro řízení pořadí, ve kterém se deklarace identity zobrazují na obrazovce.

Přidejte odkaz na technický profil ověření do technického profilu registrace, který volá REST-ValidateProfile. Nový technický profil ověření se přidá do horní části <ValidationTechnicalProfiles> kolekce definované v základní zásadě. Toto chování znamená, že až po úspěšném ověření se Azure AD B2C přesune k vytvoření účtu v adresáři.

Vyhledejte element ClaimsProviders . Přidejte nového poskytovatele nároků takto:

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

Zahrnutí deklarace identity do tokenu

Pokud chcete vrátit deklaraci propagačního kódu zpět do aplikace předávající strany, přidejte do SocialAndLocalAccounts/SignUpOrSignIn.xml souboru výstupní deklaraci identity. Výstupní deklarace identity umožní přidání deklarace identity do tokenu po úspěšné cestě uživatele a odešle se do aplikace. Upravte prvek technického profilu v části důvěřující strany tak, aby se přidal promoCode jako výstupní nárok.

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

Testování vlastních zásad

Přihlaste se do Azure Portalu.
Pokud máte přístup k více tenantům, v horní nabídce vyberte ikonu Nastavení a přepněte do tenanta Microsoft Entra ID z nabídky Adresáře a předplatná .
V levém horním rohu webu Azure Portal zvolte Všechny služby a pak vyhledejte a vyberte Registrace aplikací.
Vyberte Architekturu prostředí identit.
Vyberte Nahrát vlastní zásady a potom nahrajte soubory zásad, které jste změnili: TrustFrameworkExtensions.xmla SignUpOrSignin.xml.
Vyberte zásadu registrace nebo přihlášení, kterou jste nahráli, a klikněte na tlačítko Spustit.
Měli byste se zaregistrovat pomocí e-mailové adresy.
Klikněte na odkaz Pro registraci .
Do pole Vaše id věrnosti zadejte 1234 a klikněte na Pokračovat. V tomto okamžiku byste měli obdržet chybovou zprávu při ověření.
Přejděte na jinou hodnotu a klikněte na Pokračovat.
Token odeslaný zpět do vaší aplikace obsahuje nárok promoCode.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dlNP4-c57dO6QGTVBwaNk"
}.{
  "exp": 1584295703,
  "nbf": 1584292103,
  "ver": "1.0",
  "iss": "https://contoso.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/",
  "aud": "22223333-cccc-4444-dddd-5555eeee6666",
  "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"
  ...
}

Osvědčené postupy a postupy při řešení potíží

Použití bezserverových cloudových funkcí

Bezserverové funkce, jako jsou triggery HTTP ve službě Azure Functions, poskytují způsob, jak vytvářet koncové body rozhraní API pro použití s konektorem rozhraní API. Pomocí funkce bezserverového cloudu můžete například provést logiku ověřování a omezit registrace na konkrétní e-mailové domény. Funkce cloudu bez serverů může také integrovat webová rozhraní API, úložiště dat a další cloudové služby pro složité scénáře.

Osvědčené postupy

Zajistěte následující:

Vaše rozhraní API dodržuje smlouvy o požadavcích a odpovědích API, jak je uvedeno výše.
Adresa URL koncového bodu konektoru rozhraní API odkazuje na správný koncový bod rozhraní API.
Vaše rozhraní API explicitně kontroluje hodnoty null přijatých atributů, na které závisí.
Vaše rozhraní API implementuje metodu ověřování popsanou v rámci Zabezpečte svůj konektor rozhraní API.
Vaše API reaguje co nejrychleji, aby zajistilo plynulý uživatelský zážitek.
- Azure AD B2C bude čekat na přijetí odpovědi maximálně 10 sekund . Pokud se žádná nepřijala, při volání rozhraní API se zobrazí ještě jeden pokus (zkuste to znovu ).
- Pokud používáte bezserverovou funkci nebo škálovatelnou webovou službu, použijte plán hostování, který udržuje rozhraní API vzhůru nebo "teplé" v produkčním prostředí. Pro Azure Functions se doporučuje použít minimálně plán Premium v produkčním prostředí.
Zajistěte vysokou dostupnost vašeho rozhraní API.
Monitorujte a optimalizujte výkon podřízených rozhraní API, databází nebo jiných závislostí vašeho rozhraní API.

Důležité

Vaše koncové body musí splňovat požadavky na zabezpečení Azure AD B2C. Starší verze protokolu TLS a šifry jsou zastaralé. Další informace najdete v tématu požadavky na protokol TLS a šifrovací sadu Azure AD B2C.

Použití protokolování

Obecně je užitečné použít nástroje protokolování povolené službou webového rozhraní API, jako je Application Insights, k monitorování neočekávaných kódů chyb, výjimek a nízkého výkonu.

Monitorujte stavové kódy HTTP, které nejsou HTTP 200 nebo 400.
Stavový kód HTTP 401 nebo 403 obvykle značí problém s ověřováním. Pečlivě zkontrolujte ověřovací vrstvu vašeho rozhraní API a odpovídající konfiguraci v konektoru rozhraní API.
V případě potřeby používejte agresivnější úrovně protokolování, jako jsou například úrovně trace nebo debug, při vývoji.
Sledujte rozhraní API pro dlouhé doby odezvy.

Kromě toho Azure AD B2C protokoluje metadata o transakcích rozhraní API, ke kterým dochází během ověřování uživatelů prostřednictvím toku uživatele. Pokud chcete tyto informace najít:

Přejděte do Azure AD B2C.
Pod Aktivity vyberte protokoly auditu.
Vyfiltrujte zobrazení seznamu: Jako datum vyberte požadovaný časový interval a jako aktivitu vyberte rozhraní API, které se volalo jako součást toku uživatele.
Zkontrolujte jednotlivé protokoly. Každý řádek představuje konektor rozhraní API, který je volán během uživatelského toku. Pokud volání rozhraní API selže a dojde k opakování, bude stále reprezentován jako jeden řádek. Udává numberOfAttempts počet volání rozhraní API. Tato hodnota může být 1nebo 2. Další informace o volání rozhraní API jsou podrobně popsané v protokolech.

Příklad transakce konektoru rozhraní API během ověřování uživatele

Použití bezserverových cloudových funkcí

Bezserverové cloudové funkce, jako HTTP triggery ve službě Azure Functions, poskytují jednoduchý, vysoce dostupný a výkonný způsob, jak vytvářet koncové body API pro použití jako API konektory.

Osvědčené postupy

Zajistěte následující:

Vaše rozhraní API explicitně kontroluje hodnoty null přijatých atributů, na které závisí.
Vaše rozhraní API implementuje metodu ověřování popsanou v rámci Zabezpečte svůj konektor rozhraní API.
Vaše API reaguje co nejrychleji, aby zajistilo plynulý uživatelský zážitek.
- Pokud používáte bezserverovou funkci nebo škálovatelnou webovou službu, použijte plán hostování, který udržuje rozhraní API vzhůru nebo "teplé" v produkčním prostředí. Pro Azure Functions se doporučuje použít minimálně plán Premium.
Zajistěte vysokou dostupnost vašeho rozhraní API.
Monitorujte a optimalizujte výkon podřízených rozhraní API, databází nebo jiných závislostí vašeho rozhraní API.

Důležité

Použití protokolování

Monitorujte stavové kódy HTTP, které nejsou HTTP 200 nebo 400.
Stavový kód HTTP 401 nebo 403 obvykle značí problém s ověřováním. Pečlivě zkontrolujte ověřovací vrstvu vašeho rozhraní API a odpovídající konfiguraci v konektoru rozhraní API.
V případě potřeby používejte agresivnější úrovně protokolování, jako jsou například úrovně trace nebo debug, při vývoji.
Sledujte rozhraní API pro dlouhé doby odezvy.

Další kroky

Začněte s našimi ukázkami.
Zabezpečení konektoru rozhraní API

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-04-16

Sdílet prostřednictvím

Přidání konektoru rozhraní API do toku registrace uživatele

Požadavky

Vytvoření konektoru rozhraní API

Požadavek odeslaný do vašeho rozhraní API

Povolení konektoru rozhraní API v uživatelském toku

Po propojení se zprostředkovatelem identity během registrace

Příklad požadavku odeslaného do rozhraní API v tomto kroku

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Odpověď na pokračování

Blokující odpověď

Před vytvořením uživatele

Příklad požadavku odeslaného do rozhraní API v tomto kroku

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Odpověď na pokračování

Blokující odpověď

Odpověď na chybu ověření

Před odesláním tokenu (Preview)

Příklad požadavku odeslaného do rozhraní API v tomto kroku

Očekávané typy odpovědí z webového rozhraní API v tomto kroku

Odpověď na pokračování

Ukázkové odpovědi

Příklad odpovědi na pokračování

Příklad blokující odpovědi

Příklad odpovědi na chybu ověřování

Příprava koncového bodu rozhraní REST API

Definice nároků

Přidání technického profilu rozhraní RESTful API

Konfigurace technického profilu rozhraní RESTful API

Ověření vstupu uživatele

Zahrnutí deklarace identity do tokenu

Testování vlastních zásad

Osvědčené postupy a postupy při řešení potíží

Použití bezserverových cloudových funkcí

Osvědčené postupy

Použití protokolování

Použití bezserverových cloudových funkcí

Osvědčené postupy

Použití protokolování

Další kroky

Váš názor

Další materiály