Merge pull request #202833 from MicrosoftDocs/main

6/24 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -11116,6 +11116,17 @@
       "redirect_url": "/azure/azure-resource-manager/management/move-resources-overview",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/azure-resource-manager/management/create-private-link-access-rest.md",
+      "redirect_url": "/azure/azure-resource-manager/management/create-private-link-access-commands",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/articles/azure-resource-manager/management/manage-private-link-access-rest.md",
+      "redirect_url": "/azure/azure-resource-manager/management/manage-private-link-access-commands",
+      "redirect_document_id": false
+    },
+
     {
       "source_path_from_root": "/articles/azure-resource-manager/resource-group-move-resources.md",
       "redirect_url": "/azure/azure-resource-manager/management/move-resource-group-and-subscription",

articles/active-directory-b2c/TOC.yml

@@ -183,7 +183,7 @@
          href: enable-authentication-web-api.md
        - name: Secure API Management API
          href: secure-api-management.md
-         displayName: apim, api management, migrate, b2clogin.com 
+         displayName: api, api management, migrate, b2clogin.com 
     - name: Microsoft Power Apps
       href: /powerapps/maker/portals/configure/configure-azure-ad-b2c-provider
     - name: SAML application

articles/active-directory-b2c/application-types.md

@@ -67,7 +67,7 @@ In a web application, each execution of a [policy](user-flow-overview.md) takes
 
 Validation of the `id_token` by using a public signing key that is received from Azure AD is sufficient to verify the identity of the user. This process also sets a session cookie that can be used to identify the user on subsequent page requests.
 
-To see this scenario in action, try one of the web application sign in code samples in our [Getting started section](overview.md).
+To see this scenario in action, try one of the web application sign-in code samples in our [Getting started section](overview.md).
 
 In addition to facilitating simple sign in, a web server application might also need to access a back-end web service. In this case, the web application can perform a slightly different [OpenID Connect flow](openid-connect.md) and acquire tokens by using authorization codes and refresh tokens. This scenario is depicted in the following [Web APIs section](#web-apis).
 
@@ -134,7 +134,7 @@ In this flow, the application executes [policies](user-flow-overview.md) and rec
 
 Applications that contain long-running processes or that operate without the presence of a user also need a way to access secured resources such as web APIs. These applications can authenticate and get tokens by using their identities (rather than a user's delegated identity) and by using the OAuth 2.0 client credentials flow. Client credential flow isn't the same as on-behalf-flow and on-behalf-flow shouldn't be used for server-to-server authentication.
 
-The [OAuth 2.0 client credentials flow](./client-credentials-grant-flow.md) is currently in public preview. You can also set up client credential flow using Azure AD and the Microsoft identity platform /token endpoint (`https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token`) for a [Microsoft Graph application](microsoft-graph-get-started.md) or your own application. For more information, check out the [Azure AD token reference](../active-directory/develop/id-tokens.md) article.
+For Azure AD B2C, the [OAuth 2.0 client credentials flow](./client-credentials-grant-flow.md) is currently in public preview. However, you can set up client credential flow using Azure AD and the Microsoft identity platform `/token` endpoint (`https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token`) for a [Microsoft Graph application](microsoft-graph-get-started.md) or your own application. For more information, check out the [Azure AD token reference](../active-directory/develop/id-tokens.md) article.
 
 ## Unsupported application types
 

articles/active-directory-b2c/client-credentials-grant-flow.md

@@ -24,6 +24,8 @@ The OAuth 2.0 client credentials grant flow permits an app (confidential client)
 
 In the client credentials flow, permissions are granted directly to the application itself by an administrator. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action since there's no user involved in the authentication. This article covers the steps needed to authorize an application to call an API, and how to get the tokens needed to call that API.
 
+**This feature is in public preview.**
+
 ## App registration overview
 
 To enable your app to sign in with client credentials and call a web API, you register two applications in the Azure AD B2C directory.  

articles/active-directory-b2c/implicit-flow-single-page-application.md

@@ -1,7 +1,7 @@
 ---
 title: Single-page application sign-in using the OAuth 2.0 implicit flow in Azure Active Directory B2C
 titleSuffix: Azure AD B2C
-description: Learn how to add single-page sign in using the OAuth 2.0 implicit flow with Azure Active Directory B2C.
+description: Learn how to add single-page sign-in using the OAuth 2.0 implicit flow with Azure Active Directory B2C.
 services: active-directory-b2c
 author: kengaderdus
 manager: CelesteDG
@@ -30,7 +30,7 @@ Some frameworks, like [MSAL.js 1.x](https://github.com/AzureAD/microsoft-authent
 
 Azure AD B2C extends the standard OAuth 2.0 implicit flow to more than simple authentication and authorization. Azure AD B2C introduces the [policy parameter](user-flow-overview.md). With the policy parameter, you can use OAuth 2.0 to add policies to your app, such as sign-up, sign-in, and profile management user flows. In the example HTTP requests in this article, we use **{tenant}.onmicrosoft.com** for illustration. Replace `{tenant}` with [the name of your tenant](tenant-management.md#get-your-tenant-name) if you've one. Also, you need to have [created a user flow](tutorial-create-user-flows.md?pivots=b2c-user-flow).
 
-We use the following figure to illustrate implicit sign in flow. Each step is described in detail later in the article.
+We use the following figure to illustrate implicit sign-in flow. Each step is described in detail later in the article.
 
 ![Swimlane-style diagram showing the OpenID Connect implicit flow](./media/implicit-flow-single-page-application/convergence_scenarios_implicit.png)
 
@@ -69,7 +69,7 @@ The parameters in the HTTP GET request are explained in the table below.
 | scope | Yes | A space-separated list of scopes. A single scope value indicates to Azure AD both of the permissions that are being requested. The `openid` scope indicates a permission to sign in the user and get data about the user in the form of ID tokens. The `offline_access` scope is optional for web apps. It indicates that your app needs a refresh token for long-lived access to resources. |
 | state | No | A value included in the request that also is returned in the token response. It can be a string of any content that you want to use. Usually, a randomly generated, unique value is used, to prevent cross-site request forgery attacks. The state is also used to encode information about the user's state in the app before the authentication request occurred, for example, the page the user was on, or the user flow that was being executed. |
 | nonce | Yes | A value included in the request (generated by the app) that is included in the resulting ID token as a claim. The app can then verify this value to mitigate token replay attacks. Usually, the value is a randomized, unique string that can be used to identify the origin of the request. |
-| prompt | No | The type of user interaction that's required. Currently, the only valid value is `login`. This parameter forces the user to enter their credentials on that request. Single sign-on doesn't take effect. |
+| prompt | No | The type of user interaction that's required. Currently, the only valid value is `login`. This parameter forces the user to enter their credentials on that request. Single Sign-On doesn't take effect. |
 
 This is the interactive part of the flow. The user is asked to complete the policy's workflow. The user might have to enter their username and password, sign in with a social identity, sign up for a local account, or any other number of steps. User actions depend on how the user flow is defined.
 
@@ -238,7 +238,7 @@ ID tokens and access tokens both expire after a short period of time. Your app m
 
 ## Send a sign-out request
 
-When you want to sign the user out of the app, redirect the user to Azure AD B2C's sign-out endpoint. You can then clear the user's session in the app. If you don't redirect the user, they might be able to reauthenticate to your app without entering their credentials again because they have a valid single sign-on session with Azure AD B2C.
+When you want to sign the user out of the app, redirect the user to Azure AD B2C's sign-out endpoint. You can then clear the user's session in the app. If you don't redirect the user, they might be able to reauthenticate to your app without entering their credentials again because they have a valid Single Sign-On session with Azure AD B2C.
 
 You can simply redirect the user to the `end_session_endpoint` that is listed in the same OpenID Connect metadata document described in [Validate the ID token](#validate-the-id-token). For example:
 
@@ -255,8 +255,8 @@ GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/
 
 
 > [!NOTE]
-> Directing the user to the `end_session_endpoint` clears some of the user's single sign-on state with Azure AD B2C. However, it doesn't sign the user out of the user's social identity provider session. If the user selects the same identity provider during a subsequent sign in, the user is re-authenticated, without entering their credentials. If a user wants to sign out of your Azure AD B2C application, it doesn't necessarily mean they want to completely sign out of their Facebook account, for example. However, for local accounts, the user's session will be ended properly.
->
+> Directing the user to the `end_session_endpoint` clears some of the user's Single Sign-On state with Azure AD B2C. However, it doesn't sign the user out of the user's social identity provider session. If the user selects the same identity provider during a subsequent sign in, the user is re-authenticated, without entering their credentials. If a user wants to sign out of your Azure AD B2C application, it doesn't necessarily mean they want to completely sign out of their Facebook account, for example. However, for local accounts, the user's session will be ended properly.
+
 
 ## Next steps
 

articles/active-directory-b2c/microsoft-graph-get-started.md

@@ -9,7 +9,7 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 09/20/2021
+ms.date: 06/24/2022
 ms.author: kengaderdus
 ms.subservice: B2C
 ---
@@ -36,7 +36,7 @@ There are two modes of communication you can use when working with the Microsoft
 
 You enable the **Automated** interaction scenario by creating an application registration shown in the following sections.
 
-Although the OAuth 2.0 client credentials grant flow is not currently directly supported by the Azure AD B2C authentication service, you can set up client credential flow using Azure AD and the Microsoft identity platform /token endpoint for an application in your Azure AD B2C tenant. An Azure AD B2C tenant shares some functionality with Azure AD enterprise tenants.
+Azure AD B2C authentication service directly supports OAuth 2.0 client credentials grant flow (**currently in public preview**), but you can't use it to manage your Azure AD B2C resources via Microsoft Graph API. However, you can set up [client credential flow](../active-directory/develop/v2-oauth2-client-creds-grant-flow.md) using Azure AD and the Microsoft identity platform `/token` endpoint for an application in your Azure AD B2C tenant.
 
 ## Register management application
 

articles/active-directory/develop/scenario-web-app-sign-user-app-configuration.md

@@ -222,7 +222,7 @@ The initialization code is different depending on the platform. For ASP.NET Core
 
 # [ASP.NET Core](#tab/aspnetcore)
 
-In ASP.NET Core web apps (and web APIs), the application is protected because you have a `[Authorize]` attribute on the controllers or the controller actions. This attribute checks that the user is authenticated. The code that's initializing the application is in the *Startup.cs* file.
+In ASP.NET Core web apps (and web APIs), the application is protected because you have a `[Authorize]` attribute on the controllers or the controller actions. This attribute checks that the user is authenticated. Prior to the release of .NET 6, the code that's initializing the application is in the *Startup.cs* file.  New ASP.NET Core projects with .NET 6 no longer contain a *Startup.cs* file.  Taking its place is the *Program.cs* file.  The rest of this tutorial pertains to .NET 5 or lower.
 
 To add authentication with the Microsoft identity platform (formerly Azure AD v2.0), you'll need to add the following code. The comments in the code should be self-explanatory.