Syncing with main. Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into work-ios-mar23

Author: Heidilohr

articles/active-directory-b2c/idp-pass-through-user-flow.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 03/10/2022
+ms.date: 03/16/2023
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
@@ -150,6 +150,77 @@ When testing your applications in Azure AD B2C, it can be useful to have the Azu
 
     ![Decoded token in jwt.ms with idp_access_token block highlighted](./media/idp-pass-through-user-flow/identity-provider-pass-through-token-custom.png)
 
+## Pass the IDP refresh token (optional)
+
+The access token the identity provider returns is valid for a short period of time. Some identity providers also issue a refresh token along with the access token. Your client application can then exchange the identity provider's refresh token for a new access token when needed. 
+
+Azure AD B2C custom policy supports passing the refresh token of OAuth 2.0 identity providers, which includes [Facebook](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#facebook-with-access-token), [Google](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#facebook-with-access-token) and [GitHub](https://github.com/azure-ad-b2c/unit-tests/tree/main/Identity-providers#github-with-access-token).
+
+To pass the identity provider's refresh token, follow these steps:
+
+1. Open your *TrustframeworkExtensions.xml* file and add the following **ClaimType** element with an identifier of `identityProviderRefreshToken` to the **ClaimsSchema** element.
+    
+    ```xml
+    <ClaimType Id="identityProviderRefreshToken">
+        <DisplayName>Identity provider refresh token</DisplayName>
+        <DataType>string</DataType>
+    </ClaimType>
+    ```
+    
+1. Add the **OutputClaim** element to the **TechnicalProfile** element for each OAuth 2.0 identity provider that you would like the refresh token for. The following example shows the element added to the Facebook technical profile:
+    
+    ```xml
+    <ClaimsProvider>
+      <DisplayName>Facebook</DisplayName>
+      <TechnicalProfiles>
+        <TechnicalProfile Id="Facebook-OAUTH">
+          <OutputClaims>
+            <OutputClaim ClaimTypeReferenceId="identityProviderRefreshToken" PartnerClaimType="{oauth2:refresh_token}" />
+          </OutputClaims>
+          ...
+        </TechnicalProfile>
+      </TechnicalProfiles>
+    </ClaimsProvider>
+    ```
+
+1. Some identity providers require you to include metadata or scopes to the identity provider's technical profile.
+
+    - For Google identity provider, add two claim types `access_type` and `prompt`. Then add the following input claims to the identity provider's technical profile:
+
+        ```xml
+        <InputClaims>
+            <InputClaim ClaimTypeReferenceId="access_type" PartnerClaimType="access_type" DefaultValue="offline" AlwaysUseDefaultValue="true" />
+    
+            <!-- The refresh_token is return only on the first authorization for a given user. Subsequent authorization request doesn't return the refresh_token.
+                To fix this issue we add the prompt=consent query string parameter to the authorization request-->
+            <InputClaim ClaimTypeReferenceId="prompt" PartnerClaimType="prompt" DefaultValue="consent" AlwaysUseDefaultValue="true" />
+        </InputClaims>
+        ```
+    
+    - Other identity providers may have different methods to issue a refresh token. Follow the identity provider's audience and add the necessary elements to your identity provider's technical profile. 
+
+1. Save the changes you made in your *TrustframeworkExtensions.xml* file.
+1. Open your relying party policy file, such as *SignUpOrSignIn.xml*, and add the **OutputClaim** element to the **TechnicalProfile**:
+
+    ```xml
+    <RelyingParty>
+      <DefaultUserJourney ReferenceId="SignUpOrSignIn" />
+      <TechnicalProfile Id="PolicyProfile">
+        <OutputClaims>
+          <OutputClaim ClaimTypeReferenceId="identityProviderRefreshToken" PartnerClaimType="idp_refresh_token"/>
+        </OutputClaims>
+        ...
+      </TechnicalProfile>
+    </RelyingParty>
+    ```
+
+1. Save the changes you made in your policy's relying party policy file.
+1. Upload the *TrustframeworkExtensions.xml* file, and then the relying party policy file.
+1. [Test your policy](#test-your-policy)
+ 
+
+ 
+
 ::: zone-end
 
 ## Next steps

articles/active-directory-b2c/relyingparty.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: reference
-ms.date: 11/17/2022
+ms.date: 03/13/2023
 ms.custom: project-no-code
 ms.author: kengaderdus
 ms.subservice: B2C
@@ -78,6 +78,8 @@ The optional **RelyingParty** element contains the following elements:
 | UserJourneyBehaviors | 0:1 | The scope of the user journey behaviors. |
 | TechnicalProfile | 1:1 | A technical profile that's supported by the RP application. The technical profile provides a contract for the RP application to contact Azure AD B2C. |
 
+You need to create the **RelyingParty** child elements in the order presented in the preceding table.
+
 ## Endpoints
 
 The **Endpoints** element contains the following element:

articles/active-directory/cloud-infrastructure-entitlement-management/usage-analytics-access-keys.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: ciem
 ms.workload: identity
 ms.topic: how-to
-ms.date: 02/23/2022
+ms.date: 03/01/2023
 ms.author: jfields
 ---
 
@@ -23,6 +23,9 @@ The **Analytics** dashboard in Permissions Management provides details about ide
 - **Access Keys**: Tracks the permission usage of access keys for a given user.
 - **Serverless Functions**: Tracks assigned permissions and usage of the serverless functions.
 
+> [!NOTE] 
+> Currently, Microsoft Azure and Google Cloud Platform (GCP) do not provide significant information about access keys to return access keys data. Access Keys analytics are currently only available for Amazon Web Services (AWS) accounts. 
+
 This article describes how to view usage analytics about access keys.
 
 ## Create a query to view access keys
@@ -33,8 +36,8 @@ When you select **Access keys**, the **Analytics** dashboard provides a high-lev
 
     The following components make up the **Access Keys** dashboard:
 
-    - **Authorization System Type**: Select the authorization you want to use: Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP).
-    - **Authorization System**: Select from a **List** of accounts and **Folders***.
+    - **Authorization System Type**: Select **AWS**.
+    - **Authorization System**: Select from a **List** of accounts and **Folders**.
     - **Key Status**: Select **All**, **Active**, or **Inactive**.
     - **Key Activity State**: Select **All**, how long the access key has been used, or **Not Used**.
     - **Key Age**: Select **All** or how long ago the access key was created.
@@ -68,23 +71,23 @@ Filters can be applied in one, two, or all three categories depending on the typ
 
 ### Apply filters by authorization system type
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. Select **Apply** to run your query and display the information you selected.
 
     Select **Reset Filter** to discard your changes.
 
 
 ### Apply filters by authorization system
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. From the **Authorization System** dropdown, select accounts from a **List** of accounts and **Folders**.
 1. Select **Apply** to run your query and display the information you selected.
 
     Select **Reset Filter** to discard your changes.
 
 ### Apply filters by key status
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. From the **Authorization System** dropdown, select from a **List** of accounts and **Folders**.
 1. From the **Key Status** dropdown, select the type of key: **All**, **Active**, or **Inactive**.
 1. Select **Apply** to run your query and display the information you selected.
@@ -93,7 +96,7 @@ Filters can be applied in one, two, or all three categories depending on the typ
 
 ### Apply filters by key activity status
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. From the **Authorization System** dropdown, select from a **List** of accounts and **Folders**.
 1. From the **Key Activity State** dropdown, select **All**, the duration for how long the access key has been used, or **Not Used**.
 
@@ -103,7 +106,7 @@ Filters can be applied in one, two, or all three categories depending on the typ
 
 ### Apply filters by key age
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. From the **Authorization System** dropdown, select from a **List** of accounts and **Folders**.
 1. From the **Key Age** dropdown, select  **All** or how long ago the access key was created.
 
@@ -113,7 +116,7 @@ Filters can be applied in one, two, or all three categories depending on the typ
 
 ### Apply filters by task type
 
-1. From the **Authorization System Type** dropdown, select the authorization system you want to use: **AWS**, **Azure**, or **GCP**.
+1. From the **Authorization System Type** dropdown, select **AWS**.
 1. From the **Authorization System** dropdown, select from a **List** of accounts and **Folders**.
 1. From the **Task Type** dropdown, select  **All** tasks, **High Risk Tasks** or, for a list of tasks where users have deleted data, select **Delete tasks**.
 1. Select **Apply** to run your query and display the information you selected.

articles/active-directory/conditional-access/concept-conditional-access-cloud-apps.md

@@ -93,7 +93,6 @@ The following key applications are affected by the Office 365 cloud app:
 - Microsoft Flow
 - Microsoft Office 365 Portal
 - Microsoft Office client application
-- Microsoft Stream 
 - Microsoft To-Do WebApp
 - Microsoft Whiteboard Services
 - Office Delve

articles/active-directory/develop/custom-claims-provider-overview.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 03/06/2023
+ms.date: 03/13/2023
 ms.author: davidmu
 ms.reviewer: JasSuri
 ms.custom: aaddev 
@@ -24,6 +24,9 @@ When a user authenticates to an application, a custom claims provider can be use
 
 Key data about a user is often stored in systems external to Azure AD. For example, secondary email, billing tier, or sensitive information. Some applications may rely on these attributes for the application to function as designed. For example, the application may block access to certain features based on a claim in the token.
 
+The following short video provides an excellent overview of the Azure AD custom extensions and custom claims providers:
+> [!VIDEO https://www.youtube.com/embed/BYOMshjlwbc]
+
 Use a custom claims provider for the following scenarios:
 
 - **Migration of legacy systems** - You may have legacy identity systems such as Active Directory Federation Services (AD FS) or data stores (such as LDAP directory) that hold information about users. You'd like to migrate these applications, but can't fully migrate the identity data into Azure AD. Your apps may depend on certain information on the token, and can't be rearchitected.

articles/active-directory/develop/custom-extension-get-started.md

@@ -10,7 +10,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: how-to
 ms.workload: identity
-ms.date: 03/06/2023
+ms.date: 03/13/2023
 ms.author: davidmu
 ms.custom: aaddev
 ms.reviewer: JasSuri
@@ -21,7 +21,9 @@ ms.reviewer: JasSuri
 
 This article describes how to configure and setup a custom claims provider with the [token issuance start event](custom-claims-provider-overview.md#token-issuance-start-event-listener) type. This event is triggered right before the token is issued, and allows you to call a REST API to add claims to the token. 
 
-This how-to guide demonstrates the token issuance start event with a REST API running in Azure Functions and a sample OpenID Connect application.
+This how-to guide demonstrates the token issuance start event with a REST API running in Azure Functions and a sample OpenID Connect application. Before you start, take a look at following video, which demonstrates how to configure Azure AD custom claims provider with Function App:
+
+> [!VIDEO https://www.youtube.com/embed/r-JEsMBJ7GE]
 
 ## Prerequisites
 
@@ -488,7 +490,7 @@ To protect your Azure function, follow these steps to integrate Azure AD authent
 > [!NOTE]
 > If the Azure function app is hosted in a different Azure tenant than the tenant in which your custom extension is registered, skip to [using OpenID Connect identity provider](#51-using-openid-connect-identity-provider) step.
 
-1. In the [Azure portal](https://poral.azure.com), navigate and select the function app you previously published.
+1. In the [Azure portal](https://portal.azure.com), navigate and select the function app you previously published.
 1. Select **Authentication** in the menu on the left.
 1. Select **Add Identity provider**.  
 1. Select **Microsoft** as the identity provider.
@@ -503,7 +505,7 @@ To protect your Azure function, follow these steps to integrate Azure AD authent
 
 If you configured the [Microsoft identity provider](#step-5-protect-your-azure-function), skip this step. Otherwise, if the Azure Function is hosted under a different tenant than the tenant in which your custom extension is registered, follow these steps to protect your function:
 
-1. In the [Azure portal](https://poral.azure.com), navigate and select the function app you previously published.
+1. In the [Azure portal](https://portal.azure.com), navigate and select the function app you previously published.
 1. Select **Authentication** in the menu on the left.
 1. Select **Add Identity provider**.  
 1. Select **OpenID Connect** as the identity provider.

articles/active-directory/develop/msal-compare-msal-js-and-adal-js.md

@@ -181,7 +181,7 @@ authContext.acquireTokenRedirect("https://graph.microsoft.com", function (error,
 });
 ```
 
-MSAL.js supports both **v1.0** and **v2.0** endpoints. The **v2.0** endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:
+MSAL.js supports only the **v2.0** endpoint. The **v2.0** endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:
 
 ```javascript
 msalInstance.acquireTokenRedirect({

articles/active-directory/develop/msal-node-migration.md

@@ -171,7 +171,7 @@ authenticationContext.acquireTokenWithAuthorizationCode(
 );
 ```
 
-The v2.0 endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:
+MSAL Node supports only the **v2.0** endpoint. The v2.0 endpoint employs a *scope-centric* model to access resources. Thus, when you request an access token for a resource, you also need to specify the scope for that resource:
 
 ```javascript
 const tokenRequest = {