Merge pull request #295860 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/active-directory-b2c/claimsschema.md

@@ -110,7 +110,7 @@ In the following example, when the Identity Experience Framework interacts with
 </ClaimType>
 ```
 
-As a result, the JWT token issued by Azure AD B2C, emits the `family_name` instead of ClaimType name **surname**.
+As a result, the JWT issued by Azure AD B2C, emits the `family_name` instead of ClaimType name **surname**.
 
 ```json
 {

articles/active-directory-b2c/custom-policies-series-branch-user-journey.md

@@ -229,7 +229,7 @@ Follow the steps in [Test the custom policy](custom-policies-series-validate-use
 
 1. In the first screen, for  **Account Type**, select **Personal Account**. 
 1. For **Access Code**, enter *88888*, and then select **Continue**. 
-1. Enter the rest of the details as required, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. 
+1. Enter the rest of the details as required, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. 
 1. Repeat step 5, but this time, select **Account Type**, select **Contoso Employee Account**, and then follow the prompts.  
 
 

articles/active-directory-b2c/custom-policies-series-call-rest-api.md

@@ -35,7 +35,7 @@ In this article, you learn how to:
 
 ## Scenario overview 
 
-In [Create branching in user journey by using Azure AD B2C custom policies](custom-policies-series-branch-user-journey.md), users who select *Personal Account* need to provide a valid invitation access code to proceed. We use a static access code, but real world apps don't work this way. If the service that issues the access codes is external to your custom policy, you must make a call to that service, and pass the access code input by the user for validation. If the access code is valid, the service returns an HTTP `200 OK` response, and Azure AD B2C issues JWT token. Otherwise, the service returns an HTTP 4xx response, and the user must reenter an access code. 
+In [Create branching in user journey by using Azure AD B2C custom policies](custom-policies-series-branch-user-journey.md), users who select *Personal Account* need to provide a valid invitation access code to proceed. We use a static access code, but real world apps don't work this way. If the service that issues the access codes is external to your custom policy, you must make a call to that service, and pass the access code input by the user for validation. If the access code is valid, the service returns an HTTP `200 OK` response, and Azure AD B2C issues JWT. Otherwise, the service returns an HTTP 4xx response, and the user must reenter an access code. 
 
 :::image type="content" source="media/custom-policies-series-call-rest-api/screenshot-of-call-rest-api-call.png" alt-text="A flowchart of calling a R E S T  A P I.":::
 
@@ -228,7 +228,7 @@ Follow the steps in [Test the custom policy](custom-policies-series-validate-use
 
 1. For **Account Type**, select **Personal Account**
 1. Enter the rest of the details as required, and then select **Continue**. You see a new screen.
-1. For **Access Code**, enter *88888*, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. If you repeat the procedure, and enter a different **Access Code**, other than *88888*, you see an error, **The access code you entered is incorrect. Please try again.**
+1. For **Access Code**, enter *88888*, and then select **Continue**. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. If you repeat the procedure, and enter a different **Access Code**, other than *88888*, you see an error, **The access code you entered is incorrect. Please try again.**
 
 ## Step 5 - Enable debug mode
 

articles/active-directory-b2c/custom-policies-series-collect-user-input.md

@@ -16,15 +16,15 @@ ms.reviewer: yoelh
 ms.subservice: b2c
 
 
-#Customer intent: As a developer using Azure Active Directory B2C, I want to collect and manipulate user inputs by writing a custom policy, so that I can customize the user interface and process the inputs as claims in a JWT token.
+#Customer intent: As a developer using Azure Active Directory B2C, I want to collect and manipulate user inputs by writing a custom policy, so that I can customize the user interface and process the inputs as claims in a JWT.
 
 ---
 
 # Collect and manipulate user inputs by using Azure Active Directory B2C custom policy
 
 Azure Active Directory B2C (Azure AD B2C) custom policies allows you to collect user inputs. You can then use inbuilt methods to manipulate the user inputs.  
 
-In this article, you learn how to write a custom policy that collects user inputs via a graphical user interface. You'll then access the inputs, process then, and finally return them as claims in a JWT token. To complete this task, you'll: 
+In this article, you learn how to write a custom policy that collects user inputs via a graphical user interface. You'll then access the inputs, process then, and finally return them as claims in a JWT. To complete this task, you'll: 
 
 - Declare claims. A claim provides temporary storage of data during an Azure AD B2C policy execution. It can store information about the user, such as first name, last name, or any other claim obtained from the user or other systems. You can learn more about claims in the [Azure AD B2C custom policy overview](custom-policy-overview.md#claims). 
 
@@ -260,7 +260,7 @@ Replace the existing contents of the `HelloWorldJourney` User Journey with the f
     </OrchestrationSteps>
 ```
 
-According to the orchestration steps, we collect user inputs, set values for *objectId*, *displayName* and *message* claims, and finally send the Jwt token. 
+According to the orchestration steps, we collect user inputs, set values for *objectId*, *displayName* and *message* claims, and finally send the JWT. 
 
 ## Step 6 - Update relying party 
 
@@ -486,7 +486,7 @@ Follow the steps in [Upload custom policy file](custom-policies-series-hello-wor
 
     :::image type="content" source="media/custom-policies-series-collect-user-input/screenshot-of-accepting-user-inputs-in-custom-policy.png" alt-text="screenshot of accepting user inputs in custom policy.":::
 
-After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. It looks similar to the following JWT token snippet: 
+After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. It looks similar to the following JWT snippet: 
 
 ```json
     {

articles/active-directory-b2c/custom-policies-series-hello-world.md

@@ -141,7 +141,7 @@ If you haven't already done so, create the following encryption keys. To automat
         </ClaimsProvider>
     ```
 
-    We've declared a JWT Token Issuer. In the `CryptographicKeys` section, if you used different names to configure the signing and encryption keys in [step 1](#step-1---configure-the-signing-and-encryption-keys), make sure you use the correct value for the `StorageReferenceId`.  
+    We've declared a JWT Issuer. In the `CryptographicKeys` section, if you used different names to configure the signing and encryption keys in [step 1](#step-1---configure-the-signing-and-encryption-keys), make sure you use the correct value for the `StorageReferenceId`.  
 
 1. In the `UserJourneys` section of the `ContosoCustomPolicy.XML` file, add the following code:
 
@@ -267,7 +267,7 @@ After you upload the file, Azure AD B2C adds the prefix `B2C_1A_`, so the names
 1. For **Select application** on the overview page of the custom policy, select the web application such as *webapp1* that you previously registered. Make sure that the **Select reply URL** value is set to`https://jwt.ms`.
 1. Select **Run now** button.
 
-After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. It looks similar to the following JWT token snippet: 
+After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. It looks similar to the following JWT snippet: 
 
 ```json
     {

articles/active-directory-b2c/custom-policies-series-overview.md

@@ -38,7 +38,7 @@ This how-to guide series consists of multiple articles. We recommend that you st
 
 |Article  | What you'll learn  |
 |---------|---------|
-|[Write your first Azure Active Directory B2C custom policy - Hello World!](custom-policies-series-hello-world.md) | Write your first Azure AD B2C custom policy. You return the message *Hello World!* in the JWT token. |
+|[Write your first Azure Active Directory B2C custom policy - Hello World!](custom-policies-series-hello-world.md) | Write your first Azure AD B2C custom policy. You return the message *Hello World!* in the JWT. |
 |[Collect and manipulate user inputs by using Azure AD B2C custom policy](custom-policies-series-collect-user-input.md) | Learn how to collect inputs from users, and how to manipulate them.|
 |[Validate user inputs by using Azure Active Directory B2C custom policy](custom-policies-series-validate-user-input.md) | Learn how to validate user inputs by using techniques such as limiting user input options, regular expressions, predicates, and validation technical profiles|
 |[Create branching in user journey by using Azure Active Directory B2C custom policy](custom-policies-series-branch-user-journey.md) | Learn how to create different user experiences for different users based on the value of a claim.|

articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in-federation.md

@@ -452,7 +452,7 @@ When the custom policy runs:
 
 - **Orchestration Step 5** - This step runs if the user doesn't already exist (`objectId` doesn't exist), so the `AAD-UserWriteUsingAlternativeSecurityId` Technical Profile executes to write the social account into Microsoft Entra ID.  
 
-- **Orchestration Step 6** - Finally, step 6 assembles and returns the JWT token at the end of the policy’s execution.
+- **Orchestration Step 6** - Finally, step 6 assembles and returns the JWT at the end of the policy’s execution.
 
 ## Step 5 - Update relying party output claims 
 
@@ -466,7 +466,7 @@ In the `ContosoCustomPolicy.XML` file, locate the `RelyingParty` element, and th
     <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="sub"/>
     <OutputClaim ClaimTypeReferenceId="identityProvider" />
 ```
-We've added the identity provider (*identityProvider*) as an output claim, so it will be included in the JWT token returned to the relying party application. 
+We've added the identity provider (*identityProvider*) as an output claim, so it will be included in the JWT returned to the relying party application. 
 
 ## Step 6 - Upload policy
 
@@ -485,7 +485,7 @@ If it's the first time running this policy (social account doesn't already exist
 
 Enter or update **Display Name**, **Given Name** and the **Surname**, and then select **Continue** button.  
 
-After the policy finishes execution, you're redirected to https://jwt.ms, and you see a decoded JWT token. It looks similar to the following JWT token snippet:
+After the policy finishes execution, you're redirected to https://jwt.ms, and you see a decoded JWT. It looks similar to the following JWT snippet:
 
 ```json
 {
@@ -504,7 +504,7 @@ After the policy finishes execution, you're redirected to https://jwt.ms, and yo
 }.[Signature]
 ```
 
-Notice the identity provider, `"idp": "facebook.com"`, has been included in the JWT token. 
+Notice the identity provider, `"idp": "facebook.com"`, has been included in the JWT. 
 
 ## A combined local and social sign-in
 

articles/active-directory-b2c/custom-policies-series-sign-up-or-sign-in.md

@@ -311,7 +311,7 @@ When the custom policy runs:
 
 - **Orchestration Step 6** -  This step invokes the *UserInputMessageClaimGenerator* technical profile to assemble the user’s greeting message.
 
-- **Orchestration Step 7** - Finally, step 8 assembles and returns the JWT token at the end of the policy’s execution.
+- **Orchestration Step 7** - Finally, step 8 assembles and returns the JWT at the end of the policy’s execution.
 
 ## Step 4 - Upload policy
 

articles/active-directory-b2c/custom-policies-series-store-user.md

@@ -16,19 +16,19 @@ ms.reviewer: yoelh
 ms.subservice: b2c
 
 
-#Customer intent: As a developer using Azure Active Directory B2C, I want to create and read user accounts using custom policies, so that I can store and retrieve user information from Microsoft Entra ID storage and issue JWT tokens.
+#Customer intent: As a developer using Azure Active Directory B2C, I want to create and read user accounts using custom policies, so that I can store and retrieve user information from Microsoft Entra ID storage and issue JWTs.
 
 ---
 
 # Create and read a user account by using Azure Active Directory B2C custom policy
 
 Azure Active Directory B2C (Azure AD B2C) is built on Microsoft Entra ID, and so it uses Microsoft Entra ID storage to store user accounts. Azure AD B2C directory user profile comes with a built-in set of attributes, such as given name, surname, city, postal code, and phone number, but you can [extend the user profile with your own custom attributes](user-flow-custom-attributes.md) without requiring an external data store. 
 
-Your custom policy can connect to Microsoft Entra ID storage by using [Microsoft Entra ID technical profile](active-directory-technical-profile.md) to store, update or delete user information. In this article, you learn how to configure a set of Microsoft Entra ID technical profiles to store and read a user account before a JWT token is returned. 
+Your custom policy can connect to Microsoft Entra ID storage by using [Microsoft Entra ID technical profile](active-directory-technical-profile.md) to store, update or delete user information. In this article, you learn how to configure a set of Microsoft Entra ID technical profiles to store and read a user account before a JWT is returned. 
 
 ## Scenario overview
 
-In [Call a REST API by using Azure Active Directory B2C custom policy](custom-policies-series-call-rest-api.md) article, we collect information from the user, validated the data, called a REST API, and finally returned a JWT without storing a user account. We must store the user information so that we don't lose the information once the policy finishes execution. This time, once we collect the user information and validate it, we need to store the user information in Azure AD B2C storage, and then read before we return the JWT token. The complete process is shown in the following diagram.
+In [Call a REST API by using Azure Active Directory B2C custom policy](custom-policies-series-call-rest-api.md) article, we collect information from the user, validated the data, called a REST API, and finally returned a JWT without storing a user account. We must store the user information so that we don't lose the information once the policy finishes execution. This time, once we collect the user information and validate it, we need to store the user information in Azure AD B2C storage, and then read before we return the JWT. The complete process is shown in the following diagram.
 
 
 :::image type="content" source="media/custom-policies-series-store-user/screenshot-create-user-record.png" alt-text="A flowchart of creating a user account in Azure AD.":::   
@@ -156,7 +156,7 @@ After we collect user details by using the `UserInformationCollector` self-asser
 
 In the `ContosoCustomPolicy.XML` file, locate the `UserInformationCollector` technical profile, and then add `AAD-UserWrite` technical profile as a validation technical profile in the `ValidationTechnicalProfiles` collection. You need to add this after the `CheckCompanyDomain` validation technical profile. 
 
-We'll use the `AAD-UserRead` technical profile in the user journey orchestration steps to read the user details before issuing a JWT token.
+We'll use the `AAD-UserRead` technical profile in the user journey orchestration steps to read the user details before issuing a JWT.
 
 ## Step 4 - Update the ClaimGenerator technical profile 
 
@@ -189,7 +189,7 @@ We use the `ClaimGenerator` technical profile to execute three claims transforma
             </OutputClaimsTransformations>
         </TechnicalProfile>
     ```
-    We've broken the technical profile into two separate technical profiles. The *UserInputMessageClaimGenerator* technical profile generates the message sent as claim in the JWT token. The *UserInputDisplayNameGenerator* technical profile generates the `displayName` claim. The `displayName` claim value must be available before the `AAD-UserWrite` technical profile writes the user record into Microsoft Entra ID storage. In the new code, we remove the *GenerateRandomObjectIdTransformation* as the `objectId` is created and returned by Microsoft Entra ID after an account is created, so we don't need to generate it ourselves within the policy.
+    We've broken the technical profile into two separate technical profiles. The *UserInputMessageClaimGenerator* technical profile generates the message sent as claim in the JWT. The *UserInputDisplayNameGenerator* technical profile generates the `displayName` claim. The `displayName` claim value must be available before the `AAD-UserWrite` technical profile writes the user record into Microsoft Entra ID storage. In the new code, we remove the *GenerateRandomObjectIdTransformation* as the `objectId` is created and returned by Microsoft Entra ID after an account is created, so we don't need to generate it ourselves within the policy.
 
 1. In the `ContosoCustomPolicy.XML` file, locate the `UserInformationCollector` self-asserted technical profile, and then add the `UserInputDisplayNameGenerator` technical profile as a validation technical profile. After you do so, the `UserInformationCollector` technical profile's `ValidationTechnicalProfiles` collection should look similar to the following code:
 
@@ -249,9 +249,9 @@ Locate your `HelloWorldJourney` user journey and replace all the orchestration s
     <!--</OrchestrationSteps>-->
 ```
 
-In orchestration step `4`, we execute the `AAD-UserRead` technical profile to read the user details (to be included in the JWT token) from the created user account. 
+In orchestration step `4`, we execute the `AAD-UserRead` technical profile to read the user details (to be included in the JWT) from the created user account. 
 
-Since we don't store the `message` claim, in orchestration step `5`, we execute the `UserInputMessageClaimGenerator` to generate the `message` claim for inclusion on the JWT token.
+Since we don't store the `message` claim, in orchestration step `5`, we execute the `UserInputMessageClaimGenerator` to generate the `message` claim for inclusion on the JWT.
 
 ## Step 6 - Upload policy 
 

articles/active-directory-b2c/custom-policies-series-validate-user-input.md

@@ -357,7 +357,7 @@ Follow the steps in [Upload custom policy file](custom-policies-series-hello-wor
 
     You must correct your inputs before you continue.
 
-1. Enter correct values as suggested by the error messages, and then select **Continue** button again. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT token. The token looks similar to the following JWT token snippet: 
+1. Enter correct values as suggested by the error messages, and then select **Continue** button again. After the policy finishes execution, you're redirected to `https://jwt.ms`, and you see a decoded JWT. The token looks similar to the following JWT snippet: 
 
 ```json
     {
@@ -482,7 +482,7 @@ Use the following steps to learn how to validate user input by using validation
     1. For **Email Address**, enter an invalid email address such as *[email protected]*.
     1. Enter the rest of the details as required and select **Continue**
 
-    Since *[email protected]* isn't a valid email, you'll see an error similar to the one shown in the screenshot below. You must use a valid email address to successfully run the custom policy and receive a JWT token. 
+    Since *[email protected]* isn't a valid email, you'll see an error similar to the one shown in the screenshot below. You must use a valid email address to successfully run the custom policy and receive a JWT. 
 
     :::image type="content" source="media/custom-policies-series-validate-user-input/screenshot-of-error-due-to-invalid-email-address.png" alt-text="screenshot of error due to invalid email address.":::