Merge pull request #112051 from MicrosoftDocs/master

4/20 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -3639,7 +3639,7 @@
     },
    {
       "source_path": "articles/key-vault/about-keys-secrets-and-certificates.md",
-      "redirect_url": "/azure/key-vault",
+      "redirect_url": "/azure/key-vault/general/about-keys-secrets-certificates",
       "redirect_document_id": false
     },
    {

articles/active-directory/authentication/active-directory-certificate-based-authentication-android.md

@@ -24,7 +24,7 @@ Android devices can use certificate-based authentication (CBA) to authenticate t
 
 Configuring this feature eliminates the need to enter a username and password combination into certain mail and Microsoft Office applications on your mobile device.
 
-This topic provides you with the requirements and the supported scenarios for configuring CBA on an iOS(Android) device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China, and Germany plans.
+This topic provides you with the requirements and the supported scenarios for configuring CBA on an Android device for users of tenants in Office 365 Enterprise, Business, Education, US Government, China, and Germany plans.
 
 This feature is available in preview in Office 365 US Government Defense and Federal plans.
 

articles/active-directory/develop/active-directory-v2-protocols.md

@@ -19,9 +19,6 @@ ms.custom: aaddev
 
 The Microsoft identity platform endpoint for identity-as-a-service with industry standard protocols, OpenID Connect and OAuth 2.0. While the service is standards-compliant, there can be subtle differences between any two implementations of these protocols. The information here will be useful if you choose to write your code by directly sending and handling HTTP requests or use a third party open-source library, rather than using one of our [open-source libraries](reference-v2-libraries.md).
 
-> [!NOTE]
-> Not all Azure AD scenarios and features are supported by the Microsoft identity platform endpoint. To determine if you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 ## The basics
 
 In nearly all OAuth 2.0 and OpenID Connect flows, there are four parties involved in the exchange:
@@ -64,7 +61,7 @@ Where the `{tenant}` can take one of four different values:
 To learn how to interact with these endpoints, choose a particular app type in the [Protocols](#protocols) section and follow the links for more info.
 
 > [!TIP]
-> Any app registered in Azure AD can use the Microsoft identity platform endpoint, even if they don't sign in personal accounts.  This way, you can migrate existing applications to Microsoft identity platform and [MSAL](reference-v2-libraries.md) without re-creating your application.  
+> Any app registered in Azure AD can use the Microsoft identity platform endpoint, even if they don't sign in personal accounts.  This way, you can migrate existing applications to Microsoft identity platform and [MSAL](reference-v2-libraries.md) without re-creating your application.
 
 ## Tokens
 

articles/active-directory/develop/tutorial-v2-angular.md

@@ -50,10 +50,6 @@ This tutorial uses the following library:
 |---|---|
 |[msal.js](https://github.com/AzureAD/microsoft-authentication-library-for-js)|Microsoft Authentication Library for JavaScript Angular Wrapper|
 
-> [!NOTE]
-> *Msal.js* targets the Microsoft identity platform endpoint, which enables personal accounts, work accounts, and school accounts to sign in and acquire tokens. The Microsoft identity platform endpoint has [some limitations](../azuread-dev/azure-ad-endpoint-comparison.md#limitations).
-> To understand the differences between the v1.0 and v2.0 endpoints, see the [endpoint comparison guide](../azuread-dev/azure-ad-endpoint-comparison.md).
-
 You can find the source code for the MSAL.js library in the [AzureAD/microsoft-authentication-library-for-js](https://github.com/AzureAD/microsoft-authentication-library-for-js) repository on GitHub.
 
 <!--end-collapse-->

articles/active-directory/develop/tutorial-v2-javascript-spa.md

@@ -44,10 +44,6 @@ This guide uses the following library:
 |---|---|
 |[msal.js](https://github.com/AzureAD/microsoft-authentication-library-for-js)|Microsoft Authentication Library for JavaScript|
 
-> [!NOTE]
-> *Msal.js* targets the Microsoft identity platform endpoint, which enables personal accounts and school and work accounts to sign in and acquire tokens. The Microsoft identity platform endpoint has [some limitations](../azuread-dev/azure-ad-endpoint-comparison.md#limitations).
-> To understand the differences between the v1.0 and v2.0 endpoints, see the [endpoint comparison guide](../azuread-dev/azure-ad-endpoint-comparison.md).
-
 <!--end-collapse-->
 
 ## Set up your web server or project

articles/active-directory/develop/v2-app-types.md

@@ -19,9 +19,6 @@ ms.custom: aaddev
 
 The Microsoft identity platform (v2.0) endpoint supports authentication for a variety of modern app architectures, all of them based on industry-standard protocols [OAuth 2.0 or OpenID Connect](active-directory-v2-protocols.md). This article describes the types of apps that you can build by using Microsoft identity platform, regardless of your preferred language or platform. The information is designed to help you understand high-level scenarios before you [start working with the code](v2-overview.md#getting-started).
 
-> [!NOTE]
-> The Microsoft identity platform endpoint doesn't support all Azure Active Directory (Azure AD) scenarios and features. To determine whether you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 ## The basics
 
 You must register each app that uses the Microsoft identity platform endpoint in the new [App registrations portal](https://go.microsoft.com/fwlink/?linkid=2083908). The app registration process collects and assigns these values for your app:

articles/active-directory/develop/v2-oauth2-auth-code-flow.md

@@ -21,9 +21,6 @@ The OAuth 2.0 authorization code grant can be used in apps that are installed on
 
 This article describes how to program directly against the protocol in your application.  When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows).  Also take a look at the [sample apps that use MSAL](sample-v2-code.md).
 
-> [!NOTE]
-> Not all Azure Active Directory scenarios & features are supported by the Microsoft identity platform endpoint. To determine if you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 The OAuth 2.0 authorization code flow is described in [section 4.1 of the OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749). It's used to perform authentication and authorization in the majority of app types, including [web apps](v2-app-types.md#web-apps) and [natively installed  apps](v2-app-types.md#mobile-and-native-apps). The flow enables apps to securely acquire access_tokens that can be used to access resources secured by the Microsoft identity platform endpoint.
 
 ## Protocol diagram

articles/active-directory/develop/v2-oauth2-client-creds-grant-flow.md

@@ -23,9 +23,6 @@ This article describes how to program directly against the protocol in your appl
 
 The OAuth 2.0 client credentials grant flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service. In this scenario, the client is typically a middle-tier web service, a daemon service, or a web site. For a higher level of assurance, the Microsoft identity platform also allows the calling service to use a certificate (instead of a shared secret) as a credential.
 
-> [!NOTE]
-> The Microsoft identity platform endpoint doesn't support all Azure AD scenarios and features. To determine whether you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 In the more typical *three-legged OAuth*, a client application is granted permission to access a resource on behalf of a specific user. The permission is delegated from the user to the application, usually during the [consent](v2-permissions-and-consent.md) process. However, in the client credentials (*two-legged OAuth*) flow, permissions are granted directly to the application itself. When the app presents a token to a resource, the resource enforces that the app itself has authorization to perform an action and not the user.
 
 ## Protocol diagram

articles/active-directory/develop/v2-oauth2-device-code.md

@@ -18,13 +18,10 @@ ms.custom: aaddev
 
 # Microsoft identity platform and the OAuth 2.0 device authorization grant flow
 
-The Microsoft identity platform supports the [device authorization grant](https://tools.ietf.org/html/rfc8628), which allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer.  To enable this flow, the device has the user visit a webpage in their browser on another device to sign in.  Once the user signs in, the device is able to get access tokens and refresh tokens as needed.  
+The Microsoft identity platform supports the [device authorization grant](https://tools.ietf.org/html/rfc8628), which allows users to sign in to input-constrained devices such as a smart TV, IoT device, or printer.  To enable this flow, the device has the user visit a webpage in their browser on another device to sign in.  Once the user signs in, the device is able to get access tokens and refresh tokens as needed.
 
 This article describes how to program directly against the protocol in your application.  When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to [acquire tokens and call secured web APIs](authentication-flows-app-scenarios.md#scenarios-and-supported-authentication-flows).  Also take a look at the [sample apps that use MSAL](sample-v2-code.md).
 
-> [!NOTE]
-> The Microsoft identity platform endpoint doesn't support all Azure Active Directory scenarios and features. To determine whether you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 ## Protocol diagram
 
 The entire device code flow looks similar to the next diagram. We describe each of the steps later in this article.
@@ -58,7 +55,7 @@ scope=user.read%20openid%20profile
 
 ### Device authorization response
 
-A successful response will be a JSON object containing the required information to allow the user to sign in.  
+A successful response will be a JSON object containing the required information to allow the user to sign in.
 
 | Parameter | Format | Description |
 | ---              | --- | --- |
@@ -76,11 +73,11 @@ A successful response will be a JSON object containing the required information
 
 After receiving the `user_code` and `verification_uri`, the client displays these to the user, instructing them to sign in using their mobile phone or PC browser.
 
-If the user authenticates with a personal account (on /common or /consumers), they will be asked to sign in again in order to transfer authentication state to the device.  They will also be asked to provide consent, to ensure they are aware of the permissions being granted.  This does not apply to work or school accounts used to authenticate. 
+If the user authenticates with a personal account (on /common or /consumers), they will be asked to sign in again in order to transfer authentication state to the device.  They will also be asked to provide consent, to ensure they are aware of the permissions being granted.  This does not apply to work or school accounts used to authenticate.
 
 While the user is authenticating at the `verification_uri`, the client should be polling the `/token` endpoint for the requested token using the `device_code`.
 
-``` 
+```
 POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
 Content-Type: application/x-www-form-urlencoded
 
@@ -91,21 +88,21 @@ device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8...
 
 | Parameter | Required | Description|
 | -------- | -------- | ---------- |
-| `tenant`  | Required | The same tenant or tenant alias used in the initial request. | 
+| `tenant`  | Required | The same tenant or tenant alias used in the initial request. |
 | `grant_type` | Required | Must be `urn:ietf:params:oauth:grant-type:device_code`|
 | `client_id`  | Required | Must match the `client_id` used in the initial request. |
 | `device_code`| Required | The `device_code` returned in the device authorization request.  |
 
 ### Expected errors
 
-The device code flow is a polling protocol so your client must expect to receive errors before the user has finished authenticating.  
+The device code flow is a polling protocol so your client must expect to receive errors before the user has finished authenticating.
 
 | Error | Description | Client Action |
 | ------ | ----------- | -------------|
 | `authorization_pending` | The user hasn't finished authenticating, but hasn't canceled the flow. | Repeat the request after at least `interval` seconds. |
 | `authorization_declined` | The end user denied the authorization request.| Stop polling, and revert to an unauthenticated state.  |
 | `bad_verification_code`| The `device_code` sent to the `/token` endpoint wasn't recognized. | Verify that the client is sending the correct `device_code` in the request. |
-| `expired_token` | At least `expires_in` seconds have passed, and authentication is no longer possible with this `device_code`. | Stop polling and revert to an unauthenticated state. |   
+| `expired_token` | At least `expires_in` seconds have passed, and authentication is no longer possible with this `device_code`. | Stop polling and revert to an unauthenticated state. |
 
 ### Successful authentication response
 
@@ -131,4 +128,4 @@ A successful token response will look like:
 | `id_token`   | JWT | Issued if the original `scope` parameter included the `openid` scope.  |
 | `refresh_token` | Opaque string | Issued if the original `scope` parameter included `offline_access`.  |
 
-You can use the refresh token to acquire new access tokens and refresh tokens using the same flow documented in the [OAuth Code flow documentation](v2-oauth2-auth-code-flow.md#refresh-the-access-token).  
+You can use the refresh token to acquire new access tokens and refresh tokens using the same flow documented in the [OAuth Code flow documentation](v2-oauth2-auth-code-flow.md#refresh-the-access-token).

articles/active-directory/develop/v2-oauth2-implicit-grant-flow.md

@@ -29,9 +29,6 @@ This article describes how to program directly against the protocol in your appl
 
 However, if you prefer not to use a library in your single-page app and send protocol messages yourself, follow the general steps below.
 
-> [!NOTE]
-> Not all Azure Active Directory (Azure AD) scenarios and features are supported by the Microsoft identity platform endpoint. To determine if you should use the Microsoft identity platform endpoint, read about [Microsoft identity platform limitations](active-directory-v2-limitations.md).
-
 ## Suitable scenarios for the OAuth2 implicit grant
 
 The OAuth2 specification declares that the implicit grant has been devised to enable user-agent applications – that is to say, JavaScript applications executing within a browser. The defining characteristic of such applications is that JavaScript code is used for accessing server resources (typically a web API) and for updating the application user experience accordingly. Think of applications like Gmail or Outlook Web Access: when you select a message from your inbox, only the message visualization panel changes to display the new selection, while the rest of the page remains unmodified. This characteristic is in contrast with traditional redirect-based Web apps, where every user interaction results in a full page postback and a full page rendering of the new server response.