Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into nw-rbac2

Author: halkazwini

.openpublishing.redirection.json

@@ -23253,6 +23253,51 @@
             "redirect_url": "/azure/active-directory/develop/index-spa",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/api-find-an-api-how-to.md",
+            "redirect_url": "/azure/active-directory/develop/quickstart-configure-app-expose-web-apis",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/consent-framework-links.md",
+            "redirect_url": "/azure/active-directory/develop/permissions-consent-overview",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/authentication-protocols.md",
+            "redirect_url": "/azure/active-directory/develop/v2-oauth2-auth-code-flow",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/delegated-and-app-perms.md",
+            "redirect_url": "/azure/active-directory/develop/permissions-consent-overview",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/perms-for-given-api.md",
+            "redirect_url": "/azure/active-directory/develop/scopes-oidc",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/setup-multi-tenant-app.md",
+            "redirect_url": "/azure/active-directory/develop/howto-convert-app-to-be-multi-tenant",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/registration-config-specific-application-property-how-to.md",
+            "redirect_url": "/azure/active-directory/develop/quickstart-register-app",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/registration-config-how-to.md",
+            "redirect_url": "/azure/active-directory/develop/quickstart-register-app",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/active-directory/develop/registration-config-sso-how-to.md",
+            "redirect_url": "/azure/active-directory/develop/quickstart-register-app",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/networking/azure-orbital-overview.md",
             "redirect_url": "/azure/orbital/overview",

articles/active-directory/develop/api-find-an-api-how-to.md

@@ -1,31 +1,30 @@
 ---
-title: Microsoft identity platform authentication flows & app scenarios
+title: Microsoft identity platform app types and authentication flows
 description: Learn about application scenarios for the Microsoft identity platform, including authenticating identities, acquiring tokens, and calling protected APIs.
 services: active-directory
 author: cilwerner
 manager: CelesteDG
 
-ms.assetid:
 ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 05/05/2022
+ms.date: 08/11/2023
 ms.author: cwerner
 ms.reviewer: jmprieur
 ms.custom: aaddev, identityplatformtop40, scenarios:getting-started, has-adal-ref
-#Customer intent: As an app developer, I want to learn about authentication flows and application scenarios so I can create applications protected by the Microsoft identity platform.
+# Customer intent: As an app developer, I want to learn about authentication flows and application scenarios so I can create applications protected by the Microsoft identity platform.
 ---
 
-# Authentication flows and application scenarios
+# Microsoft identity platform app types and authentication flows
 
 The Microsoft identity platform supports authentication for different kinds of modern application architectures. All of the architectures are based on the industry-standard protocols [OAuth 2.0 and OpenID Connect](./v2-protocols.md). By using the [authentication libraries for the Microsoft identity platform](reference-v2-libraries.md), applications authenticate identities and acquire tokens to access protected APIs.
 
 This article describes authentication flows and the application scenarios that they're used in.
 
 ## Application categories
 
-Tokens can be acquired from several types of applications, including:
+[Security tokens](./security-tokens.md) can be acquired from several types of applications, including:
 
 - Web apps
 - Mobile apps
@@ -40,7 +39,7 @@ The following sections describe the categories of applications.
 
 Authentication scenarios involve two activities:
 
-- **Acquiring security tokens for a protected web API**: We recommend that you use the [Microsoft Authentication Library (MSAL)](reference-v2-libraries.md), developed and supported by Microsoft.
+- **Acquiring security tokens for a protected web API**: We recommend that you use the [Microsoft Authentication Library (MSAL)](msal-overview.md), developed and supported by Microsoft.
 - **Protecting a web API or a web app**: One challenge of protecting these resources is validating the security token. On some platforms, Microsoft offers [middleware libraries](reference-v2-libraries.md).
 
 ### With users or without users
@@ -75,7 +74,7 @@ The available authentication flows differ depending on the sign-in audience. Som
 
 For more information, see [Supported account types](v2-supported-account-types.md#account-type-support-in-authentication-flows).
 
-## Application scenarios
+## Application types
 
 The Microsoft identity platform supports authentication for these app architectures:
 
@@ -127,7 +126,7 @@ For a desktop app to call a web API that signs in users, use the interactive tok
 
 There's another possibility for Windows-hosted applications on computers joined either to a Windows domain or by Azure Active Directory (Azure AD). These applications can silently acquire a token by using [integrated Windows authentication](https://aka.ms/msal-net-iwa).
 
-Applications running on a device without a browser can still call an API on behalf of a user. To authenticate, the user must sign in on another device that has a web browser. This scenario requires that you use the [device code flow](https://aka.ms/msal-net-device-code-flow).
+Applications running on a device without a browser can still call an API on behalf of a user. To authenticate, the user must sign in on another device that has a web browser. This scenario requires that you use the [device code flow](v2-oauth2-device-code.md).
 
 ![Device code flow](media/scenarios/device-code-flow-app.svg)
 
@@ -147,7 +146,7 @@ Similar to a desktop app, a mobile app calls the interactive token-acquisition m
 
 MSAL iOS and MSAL Android use the system web browser by default. However, you can direct them to use the embedded web view instead. There are specificities that depend on the mobile platform: Universal Windows Platform (UWP), iOS, or Android.
 
-Some scenarios, like those that involve Conditional Access related to a device ID or a device enrollment, require a broker to be installed on the device. Examples of brokers are Microsoft Company Portal on Android and Microsoft Authenticator on Android and iOS. MSAL can now interact with brokers. For more information about brokers, see [Leveraging brokers on Android and iOS](https://github.com/AzureAD/azure-activedirectory-library-for-dotnet/wiki/leveraging-brokers-on-Android-and-iOS).
+Some scenarios, like those that involve Conditional Access related to a device ID or a device enrollment, require a broker to be installed on the device. Examples of brokers are Microsoft Company Portal on Android and Microsoft Authenticator on Android and iOS. MSAL can now interact with brokers. For more information about brokers, see [Leveraging brokers on Android and iOS](msal-net-use-brokers-with-xamarin-apps.md).
 
 For more information, see [Mobile app that calls web APIs](scenario-mobile-overview.md).
 

articles/active-directory/develop/authentication-flows-app-scenarios.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 07/15/2022
+ms.date: 08/11/2023
 ms.author: cwerner
 ms.reviewer: saeeda
 ms.custom: aaddev, has-adal-ref
@@ -45,8 +45,8 @@ The authority you specify in your code needs to be consistent with the **Support
 The authority can be:
 
 - An Azure AD cloud authority.
-- An Azure AD B2C authority. See [B2C specifics](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/AAD-B2C-specifics).
-- An Active Directory Federation Services (AD FS) authority. See [AD FS support](https://aka.ms/msal-net-adfs-support).
+- An Azure AD B2C authority. See [B2C specifics](msal-net-b2c-considerations.md).
+- An Active Directory Federation Services (AD FS) authority. See [AD FS support](msal-net-adfs-support.md).
 
 Azure AD cloud authorities have two parts:
 
@@ -129,7 +129,7 @@ You can override the redirect URI by using the `RedirectUri` property (for examp
 - `RedirectUriOnAndroid` = "msauth-5a434691-ccb2-4fd1-b97b-b64bcfbc03fc://com.microsoft.identity.client.sample";
 - `RedirectUriOnIos` = $"msauth.{Bundle.ID}://auth";
 
-For more iOS details, see [Migrate iOS applications that use Microsoft Authenticator from ADAL.NET to MSAL.NET](msal-net-migration-ios-broker.md) and [Leveraging the broker on iOS](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Leveraging-the-broker-on-iOS).
+For more iOS details, see [Migrate iOS applications that use Microsoft Authenticator from ADAL.NET to MSAL.NET](msal-net-migration-ios-broker.md) and [Leveraging the broker on iOS](msal-net-use-brokers-with-xamarin-apps.md).
 For more Android details, see [Brokered auth in Android](msal-android-single-sign-on.md).
 
 ### Redirect URI for confidential client apps

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

@@ -93,8 +93,10 @@ Depending on the permissions they require, some applications might require an ad
 
 Preauthorization allows a resource application owner to grant permissions without requiring users to see a consent prompt for the same set of permissions that have been preauthorized. This way, an application that has been preauthorized won't ask users to consent to permissions. Resource owners can preauthorize client apps in the Azure portal or by using PowerShell and APIs, like Microsoft Graph.
 
-## Next steps
+## See also
 
 - [Delegated access scenario](delegated-access-primer.md)
 - [User and admin consent overview](../manage-apps/user-admin-consent-overview.md)
 - [OpenID connect scopes](scopes-oidc.md)
+-- [Making your application multi-tenant](./howto-convert-app-to-be-multi-tenant.md)
+- [AzureAD Microsoft Q&A](/answers/topics/azure-active-directory.html)

articles/active-directory/develop/consent-framework-links.md

@@ -31,6 +31,8 @@ By specifying a web API's scopes in your client app's registration, the client a
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 
+Access to APIs require configuration of access scopes and roles. If you want to expose your resource application web APIs to client applications, configure access scopes and roles for the API. If you want a client application to access a web API, configure permissions to access the API in the app registration.
+
 In the first scenario, you grant a client app access to your own web API, both of which you should have registered as part of the prerequisites. If you don't yet have both a client app and a web API registered, complete the steps in the two [Prerequisites](#prerequisites) articles.
 
 This diagram shows how the two app registrations relate to one another. In this section, you add permissions to the client app's registration.