Merge pull request #113284 from MicrosoftDocs/master

4/29 PM Publish

Author: huypub

.openpublishing.redirection.json

@@ -23991,6 +23991,11 @@
       "redirect_url": "/azure/active-directory/develop/authentication-scenarios",
       "redirect_document_id": true
     },
+    {
+      "source_path": "articles/active-directory/develop/authentication-scenarios.md",
+      "redirect_url": "/azure/active-directory/develop/authentication-vs-authorization",
+      "redirect_document_id": true
+    },
     {
       "source_path": "articles/active-directory/develop/active-directory-v2-app-registration.md",
       "redirect_url": "/azure/active-directory/develop/quickstart-v2-register-an-app",

articles/active-directory/conditional-access/concept-conditional-access-grant.md

@@ -80,7 +80,6 @@ This setting applies to the following iOS and Android apps:
 - Microsoft Kaizala
 - Microsoft Launcher
 - Microsoft Office
-- Microsoft Office Hub
 - Microsoft OneDrive
 - Microsoft OneNote
 - Microsoft Outlook

articles/active-directory/develop/TOC.yml

@@ -103,7 +103,15 @@
   items:
   - name: Authentication basics
     displayName: Auth basics
-    href: authentication-scenarios.md
+    items:
+    - name: Authentication vs. authorization
+      href: authentication-vs-authorization.md
+    - name: Security tokens
+      href: security-tokens.md
+    - name: Application model
+      href: application-model.md
+    - name: App sign-in flow
+      href: app-sign-in-flow.md
   - name: Authentication flows and app scenarios
     displayName: Auth flows
     href: authentication-flows-app-scenarios.md

articles/active-directory/develop/app-sign-in-flow.md

@@ -0,0 +1,82 @@
+---
+title: App sign-in flow with Microsoft identity platform | Azure
+titleSuffix: Microsoft identity platform
+description: Learn about the sign-in flow of web, desktop, and mobile apps in Microsoft identity platform (v2.0).
+services: active-directory
+author: rwike77
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.topic: conceptual
+ms.workload: identity
+ms.date: 04/28/2020
+ms.author: ryanwi
+ms.reviewer: jmprieur, saeeda, sureshja, hirsin
+ms.custom: aaddev, identityplatformtop40, scenarios:getting-started
+#Customer intent: As an application developer, I want to understand the sign-in flow of web, desktop, and mobile apps in Microsoft identity platform
+---
+
+# App sign-in flow with Microsoft identity platform
+
+This topic discusses the basic sign-in flow for web, desktop, and mobile apps using Microsoft identity platform. See [Authentication flows and app scenarios](authentication-flows-app-scenarios.md) to learn about sign-in scenarios supported by Microsoft identity platform.
+
+## Web app sign-in flow
+
+When a user navigates in the browser to a web app, the following happens:
+
+* The web app determines whether the user is authenticated.
+* If the user isn't authenticated, the web app delegates to Azure AD to sign in the user. That sign in will be compliant with the policy of the organization, which may mean asking the user to enter their credentials, using multi-factor-authentication, or not using a password at all (for example using Windows Hello).
+* The user is asked to consent to the access that the client app needs. This is why client apps need to be registered with Azure AD, so that Microsoft identity platform can deliver tokens representing the access that the user has consented to.
+
+When the user has successfully authenticated:
+
+* Microsoft identity platform sends a token to the web app.
+* A cookie is saved, associated with Azure AD's domain, that contains the identity of the user in the browser's cookie jar. The next time an app uses the browser to navigate to the Microsoft identity platform authorization endpoint, the browser presents the cookie so that the user doesn't have to sign in again. This is also the way that SSO is achieved. The cookie is produced by Azure AD and can only be understood by Azure AD.
+* The web app then validates the token. If the validation succeeds, the web app displays the protected page and saves a session cookie in the browser's cookie jar. When the user navigates to another page, the web app knows that the user is authenticated based on the session cookie.
+
+The following sequence diagram summarizes this interaction:
+
+![web app authentication process](media/authentication-scenarios/web-app-how-it-appears-to-be.png)
+
+### How a web app determines if the user is authenticated
+
+Web app developers can indicate whether all or only certain pages require authentication. For example, in ASP.NET/ASP.NET Core, this is done by adding the `[Authorize]` attribute to the controller actions.
+
+This attribute causes ASP.NET to check for the presence of a session cookie containing the identity of the user. If a cookie isn't present, ASP.NET redirects authentication to the specified identity provider. If the identity provider is Azure AD, the web app redirects authentication to `https://login.microsoftonline.com`, which displays a sign-in dialog.
+
+### How a web app delegates sign-in to Microsoft identity platform and obtains a token
+
+User authentication happens via the browser. The OpenID protocol uses standard HTTP protocol messages.
+
+* The web app sends an HTTP 302 (redirect) to the browser to use Microsoft identity platform.
+* When the user is authenticated, Microsoft identity platform sends the token to the web app by using a redirect through the browser.
+* The redirect is provided by the web app in the form of a redirect URI. This redirect URI is registered with the Azure AD application object. There can be several redirect URIs because the application may be deployed at several URLs. So the web app will also need to specify the redirect URI to use.
+* Azure AD verifies that the redirect URI sent by the web app is one of the registered redirect URIs for the app.
+
+## Desktop and mobile app sign-in flow
+
+The flow described above applies, with slight differences, to desktop and mobile applications.
+
+Desktop and mobile applications can use an embedded Web control, or a system browser, for authentication. The following diagram shows how a Desktop or mobile app uses the Microsoft authentication library (MSAL) to acquire access tokens and call web APIs.
+
+![Desktop app how it appears to be](media/authentication-scenarios/desktop-app-how-it-appears-to-be.png)
+
+MSAL uses a browser to get tokens. As with web apps, authentication is delegated to Microsoft identity platform.
+
+Because Azure AD saves the same identity cookie in the browser as it does for web apps, if the native or mobile app uses the system browser it will immediately get SSO with the corresponding web app.
+
+By default, MSAL uses the system browser. The exception is .NET Framework desktop applications where an embedded control is used to provide a more integrated user experience.
+
+## Next steps
+
+For other topics covering authentication and authorization basics:
+
+* See [Authentication vs. authorization](authentication-vs-authorization.md) to learn about the basic concepts of authentication and authorization in Microsoft identity platform.
+* See [Security tokens](security-tokens.md) to learn how access tokens, refresh tokens, and ID tokens are used in authentication and authorization.
+* See [Application model](application-model.md) to learn about the process of registering your application so it can integrate with Microsoft identity platform.
+
+To learn more about app sign-in flow:
+
+* See [Authentication flows and app scenarios](authentication-flows-app-scenarios.md) to learn more about other scenarios for authenticating users supported by Microsoft identity platform.
+* See [MSAL libraries](msal-overview.md) to learn about the Microsoft libraries that help you develop applications that work with Microsoft Accounts, Azure AD accounts, and Azure AD B2C users all in a single, streamlined programming model.

articles/active-directory/develop/application-model.md

@@ -0,0 +1,86 @@
+---
+title: Application model | Azure
+titleSuffix: Microsoft identity platform
+description: Learn about the process of registering your application so it can integrate with Microsoft identity platform (v2.0).
+services: active-directory
+author: rwike77
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.topic: conceptual
+ms.workload: identity
+ms.date: 04/28/2020
+ms.author: ryanwi
+ms.reviewer: jmprieur, saeeda, sureshja, hirsin
+ms.custom: aaddev, identityplatformtop40, scenarios:getting-started
+#Customer intent: As an application developer, I want to understand how to register an application so it can integrate with Microsoft identity platform
+---
+
+# Application model
+
+Applications can sign in users themselves or delegate sign-in to an identity provider. This topic discusses the steps that are required to register an application with Microsoft identity platform.
+
+## Registering an application
+
+For an identity provider to know that a user has access to a particular app, both the user and the application must be registered with the identity provider. When you register your application with Azure AD, you are providing an identity configuration for your application that allows it to integrate with Microsoft identity platform. Registering the app also allows you to:
+
+* Customize the branding of your application in the sign-in dialog. This is important because this is the first experience a user will have with your app.
+* Decide if you want to let users sign in only if they belong to your organization. This is a single tenant application. Or allow users to sign in using any work or school account. This is a multi-tenant application. You can also allow personal Microsoft accounts, or a social account from LinkedIn, Google, and so on.
+* Request scope permissions. For example, you can request the "user.read" scope, which grants permission to read the profile of the signed-in user.
+* Define scopes that define access to your web API. Typically, when an app wants to access your API, it will need to request permissions to the scopes you define.
+* Share a secret with Microsoft identity platform that proves the app's identity.  This is relevant in the case where the app is a confidential client application. A confidential client application is an application that can hold credentials securely. They require a trusted backend server to store the credentials.
+
+Once registered, the application will be given a unique identifier that the app shares with Microsoft identity platform when it requests tokens. If the app is a [confidential client application](developer-glossary.md#client-application), it will also share the secret or the public key-depending on whether certificates or secrets were used.
+
+Microsoft identity platform represents applications using a model that fulfills two main functions:
+
+* Identify the app by the authentication protocols it supports
+* Provide all the identifiers, URLs, secrets, and related information that are needed to authenticate
+
+Microsoft identity platform:
+
+* Holds all the data required to support authentication at runtime
+* Holds all the data for deciding what resources an app might need to access, and under what circumstances a given request should be fulfilled
+* Provides infrastructure for implementing app provisioning within the app developer's tenant, and to any other Azure AD tenant
+* Handles user consent during token request time and facilitate the dynamic provisioning of apps across tenants
+
+**Consent** is the process of a resource owner granting authorization for a client application to access protected resources, under specific permissions, on behalf of the resource owner. Microsoft identity platform:
+
+* Enables users and administrators to dynamically grant or deny consent for the app to access resources on their behalf.
+* Enables administrators to ultimately decide what apps are allowed to do and which users can use specific apps, and how the directory resources are accessed.
+
+## Multi-tenant apps
+
+In Microsoft identity platform, an [application object](developer-glossary.md#application-object) describes an application. At deployment time, Microsoft identity platform uses the application object as a blueprint to create a [service principal](developer-glossary.md#service-principal-object), which represents a concrete instance of an application within a directory or tenant. The service principal defines what the app can actually do in a specific target directory, who can use it, what resources it has access to, and so on. Microsoft identity platform creates a service principal from an application object through [consent](developer-glossary.md#consent).
+
+The following diagram shows a simplified Microsoft identity platform provisioning flow driven by consent. It shows two tenants: *A* and *B*.
+
+* *Tenant A* owns the application.
+* *Tenant B* is instantiating the application via a service principal.
+
+![Simplified provisioning flow driven by consent](./media/authentication-scenarios/simplified-provisioning-flow-consent-driven.svg)
+
+In this provisioning flow:
+
+1. A user from tenant B attempts to sign in with the app, the authorization endpoint requests a token for the application.
+1. The user credentials are acquired and verified for authentication.
+1. The user is prompted to provide consent for the app to gain access to tenant B.
+1. Microsoft identity platform uses the application object in tenant A as a blueprint for creating a service principal in tenant B.
+1. The user receives the requested token.
+
+You can repeat this process for additional tenants. Tenant A retains the blueprint for the app (application object). Users and admins of all the other tenants where the app is given consent keep control over what the application is allowed to do via the corresponding service principal object in each tenant. For more information, see [Application and service principal objects in Microsoft identity platform](app-objects-and-service-principals.md).
+
+## Next steps
+
+For other topics covering authentication and authorization basics:
+
+* See [Authentication vs. authorization](authentication-vs-authorization.md) to learn about the basic concepts of authentication and authorization in Microsoft identity platform.
+* See [Security tokens](security-tokens.md) to learn how access tokens, refresh tokens, and ID tokens are used in authentication and authorization.
+* See [App sign-in flow](app-sign-in-flow.md) to learn about the sign-in flow of web, desktop, and mobile apps in Microsoft identity platform.
+
+To learn more about the application model:
+
+* See [How and why applications are added to Azure AD](active-directory-how-applications-are-added.md) for more information on application objects and service principals in Microsoft identity platform.
+* See [Tenancy in Azure Active Directory](single-and-multi-tenant-apps.md) for more information on single-tenant apps and multi-tenant apps.
+* See [Azure Active Directory B2C documentation](https://docs.microsoft.com/azure/active-directory-b2c) for more information on how Azure AD also provides Azure Active Directory B2C so that organizations can sign in users, typically customers, using social identities like a Google account.

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

@@ -41,7 +41,7 @@ Applications can be categorized as in the following list:
 - [Protected resources vs. client applications](#protected-resources-vs-client-applications): Some scenarios are about protecting resources like web apps or web APIs. Other scenarios are about acquiring a security token to call a protected web API.
 - [With users or without users](#with-users-or-without-users): Some scenarios involve a signed-in user, but others, like daemon scenarios, don't involve a user.
 - [Single-page, public client, and confidential client applications](#single-page-public-client-and-confidential-client-applications): These types are three large categories of applications. Each is used with different libraries and objects.
-- [Sign-in audience](v2-supported-account-types.md#certain-authentication-flows-dont-support-all-the-account-types): The available authentication flows differ depending on the sign-in audience. Some flows are available only for work or school accounts. And some are available both for work or school accounts and for personal Microsoft accounts. The allowed audience depends on the authentication flows.
+- [Sign-in audience](v2-supported-account-types.md): The available authentication flows differ depending on the sign-in audience. Some flows are available only for work or school accounts. And some are available both for work or school accounts and for personal Microsoft accounts. The allowed audience depends on the authentication flows.
 - [Supported OAuth 2.0 flows](#scenarios-and-supported-authentication-flows):  Authentication flows are used to implement the application scenarios that are requesting tokens. There isn't a one-to-one mapping between application scenarios and authentication flows.
 - [Supported platforms](#scenarios-and-supported-platforms-and-languages): Not all application scenarios are available for every platform.