Merge pull request #27 from MicrosoftDocs/master

update private branch

Author: swkrish

.openpublishing.redirection.json

@@ -5,3 +5,4 @@
 # articles/virtual-machines/windows/  @iainfoulds @cynthn
 # articles/application-insights/  @SergeyKanzhelev
 # articles/cosmos-db/ @mimig1
+articles/cognitive-services/ @nitinme @tchristiani @cjgronlund

CODEOWNERS

@@ -72,8 +72,6 @@
       href: active-directory-b2c-devquickstarts-web-dotnet-susi.md
     - name: ASP.NET Core
       href: https://github.com/Azure-Samples/active-directory-b2c-dotnetcore-webapp
-    - name: Node.js
-      href: active-directory-b2c-devquickstarts-web-node.md
   - name: Single page apps
     items:
     - name: Overview

articles/active-directory-b2c/TOC.yml

@@ -56,7 +56,13 @@ Learn more about the types of tokens and claims available to an application in t
 
 In a web application, each execution of a [policy](active-directory-b2c-reference-policies.md) takes these high-level steps:
 
-![Web App Swimlanes Image](./media/active-directory-b2c-apps/webapp.png)
+1. The user browses to the web application.
+2. The web application redirects the user to Azure AD B2C indicating the policy to execute.
+3. The user completes policy.
+4. Azure AD B2C returns an `id_token` to the browser.
+5. The `id_token` is posted to the redirect URI.
+6. The `id_token` is validated and a session cookie is set.
+7. A secure page is returned to the user.
 
 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 also sets a session cookie that can be used to identify the user on subsequent page requests.
 
@@ -85,7 +91,15 @@ The web API can then use the token to verify the API caller's identity and to ex
 
 A web API can receive tokens from many types of clients, including web applications, desktop and mobile applications, single page applications, server-side daemons, and other web APIs. Here's an example of the complete flow for a web application that calls a web API:
 
-![Web App Web API Swimlanes Image](./media/active-directory-b2c-apps/webapi.png)
+1. The web application executes a policy and the user completes the user experience.
+2. Azure AD B2C returns an `access_token` and an authorization code to the browser.
+3. The browser posts the `access_token` and authorization code to the redirect URI.
+4. The web server validates the `access token` and sets a session cookie.
+5. The `access_token` is provided to Azure AD B2C with the authorization code, application client ID, and credentials.
+6. The `access_token` and `refresh_token` are returned to the web server.
+7. The web API is called with the `access_token` in an authorization header.
+8. The web API validates the token.
+9. Secure data is returned to the web server.
 
 To learn more about authorization codes, refresh tokens, and the steps for getting tokens, read about the [OAuth 2.0 protocol](active-directory-b2c-reference-oauth-code.md).
 
@@ -102,8 +116,6 @@ In this flow, the application executes [policies](active-directory-b2c-reference
 >
 >
 
-![Native App Swimlanes Image](./media/active-directory-b2c-apps/native.png)
-
 ## Current limitations
 
 Azure AD B2C does not currently support the following types of apps, but they are on the roadmap. 

articles/active-directory-b2c/active-directory-b2c-apps.md

@@ -23,7 +23,7 @@ Azure Active Directory (Azure AD) B2C tenants tend to be very large. This means
 For B2C tenants, there are two primary modes of communicating with the Graph API.
 
 * For interactive, run-once tasks, you should act as an administrator account in the B2C tenant when you perform the tasks. This mode requires an administrator to sign in with credentials before that admin can perform any calls to the Graph API.
-* For automated, continuous tasks, you should use some type of service account that you provide with the necessary privileges to perform management tasks. In Azure AD, you can do this by registering an application and authenticating to Azure AD. This is done by using an **Application ID** that uses the [OAuth 2.0 client credentials grant](../active-directory/develop/active-directory-authentication-scenarios.md#daemon-or-server-application-to-web-api). In this case, the application acts as itself, not as a user, to call the Graph API.
+* For automated, continuous tasks, you should use some type of service account that you provide with the necessary privileges to perform management tasks. In Azure AD, you can do this by registering an application and authenticating to Azure AD. This is done by using an **Application ID** that uses the [OAuth 2.0 client credentials grant](../active-directory/develop/authentication-scenarios.md#daemon-or-server-application-to-web-api). In this case, the application acts as itself, not as a user, to call the Graph API.
 
 In this article, you learn how to perform the automated-use case. You'll build a .NET 4.5 `B2CGraphClient` that performs user create, read, update, and delete (CRUD) operations. The client will have a Windows command-line interface (CLI) that allows you to invoke various methods. However, the code is written to behave in a noninteractive, automated fashion.