Merge branch 'master' into patch-1

Author: ktoliver

.openpublishing.redirection.json

@@ -101,8 +101,10 @@
   items:
   - name: App integration
     items:
-    - name: Register an application
+    - name: Register a web application
       href: tutorial-register-applications.md
+    - name: Register a single-page application (SPA)
+      href: tutorial-register-spa.md
     - name: Register a SAML service provider
       href: connect-with-saml-service-providers.md
       displayName: SP, RP, service provider, connect

articles/active-directory-b2c/TOC.yml

@@ -8,7 +8,7 @@ manager: celestedg
 ms.service: active-directory
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 05/12/2020
+ms.date: 10/19/2020
 ms.custom: project-no-code
 ms.author: mimart
 ms.subservice: B2C
@@ -46,10 +46,15 @@ The following example shows scopes encoded in a URL:
 scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access
 ```
 
-If you request more scopes than what is granted for your client application, the call succeeds if at least one permission is granted. The **scp** claim in the resulting access token is populated with only the permissions that were successfully granted. The OpenID Connect standard specifies several special scope values. The following scopes represent the permission to access the user's profile:
+If you request more scopes than what is granted for your client application, the call succeeds if at least one permission is granted. The **scp** claim in the resulting access token is populated with only the permissions that were successfully granted. 
+
+### OpenID Connect scopes
+
+The OpenID Connect standard specifies several special scope values. The following scopes represent the permission to access the user's profile:
 
 - **openid** - Requests an ID token.
 - **offline_access** - Requests a refresh token using [Auth Code flows](authorization-code-flow.md).
+- **00000000-0000-0000-0000-000000000000** - Using the client ID as the scope indicates that your app needs an access token that can be used against your own service or web API, represented by the same client ID.
 
 If the **response_type** parameter in an `/authorize` request includes `token`, the **scope** parameter must include at least one resource scope other than `openid` and `offline_access` that will be granted. Otherwise, the `/authorize` request fails.
 

articles/active-directory-b2c/access-tokens.md

@@ -30,7 +30,7 @@ To register an application in your Azure AD B2C tenant, you can use our new unif
 1. Select **Register**.
 1. Record the **Application (client) ID** for use in your web API's code.
 
-If you have an application that implements the implicit grant flow, for example a JavaScript-based single-page application (SPA), you can enable the flow by following these steps:
+If you have an application that implements the implicit grant flow, for example a [JavaScript-based single-page application (SPA)](tutorial-register-spa.md), you can enable the flow by following these steps:
 
 1. Under **Manage**, select **Authentication**.
 1. Under **Implicit grant**, select both the **Access tokens** and **ID tokens** check boxes.

articles/active-directory-b2c/add-web-api-application.md

@@ -49,13 +49,13 @@ The Azure AD B2C App registrations experience is based on the general [App Regis
 ## New supported account types
 
 In the new experience, you select a support account type from the following options:
-- Accounts in this organizational directory only.
-- Accounts in any organizational directory (Any Azure AD directory – Multitenant).
-- Accounts in any organizational directory or any identity provider. For authenticating users with Azure AD B2C.
+- Accounts in this organizational directory only
+- Accounts in any organizational directory (Any Azure AD directory – Multitenant)
+- Accounts in any identity provider or organizational directory (for authenticating users with user flows)
 
 To understand the different account types, select **Help me choose** in the creation experience.
 
-In the legacy experience, apps were always created as customer-facing applications. For those apps, the account type is set to **Accounts in any organizational directory or any identity provider. For authenticating users with Azure AD B2C**.
+In the legacy experience, apps were always created as customer-facing applications. For those apps, the account type is set to **Accounts in any identity provider or organizational directory (for authenticating users with user flows)**.
 > [!NOTE]
 > This option is required to be able to run Azure AD B2C user flows to authenticate users for this application. Learn [how to register an application for use with user flows.](tutorial-register-applications.md)
 
@@ -92,13 +92,12 @@ In the new experience, instead of **Keys**, you use the **Certificates & secrets
 
 ## Features not applicable in Azure AD B2C tenants
 The following Azure AD app registrations capabilities are not applicable to or available in Azure AD B2C tenants:
-- **Roles and administrators** - This requires an Azure AD Premium P1 or P2 license that is not currently available for Azure AD B2C.
+- **Roles and administrators** - Not currently available for Azure AD B2C.
 - **Branding** - UI/UX customization is configured in the **Company branding** experience or as part of a user flow. Learn to [customize the user interface in Azure Active Directory B2C](customize-ui-overview.md).
 - **Publisher domain verification** - Your app is registered on *.onmicrosoft.com*, which isn't a verified domain. Additionally, the publisher domain is primarily used for granting user consent, which doesn't apply to Azure AD B2C apps for user authentication. [Learn more about publisher domain](https://docs.microsoft.com/azure/active-directory/develop/howto-configure-publisher-domain).
 - **Token configuration** - The token is configured as part of a user flow rather than an app.
 - The **Quickstarts** experience is currently not available for Azure AD B2C tenants.
-- The **Integration assistant** blade is currently not available for Azure AD B2C tenants.
-
+<!-- - The **Integration assistant** blade is currently not available for Azure AD B2C tenants. -->
 
 ## Limitations
 The new experience has the following limitations:

articles/active-directory-b2c/app-registrations-training-guide.md

@@ -15,7 +15,7 @@ ms.subservice: B2C
 
 ---
 # Application types that can be used in Active Directory B2C
-
+ 
 Azure Active Directory B2C (Azure AD B2C) supports authentication for a variety of modern application architectures. All of them are based on the industry standard protocols [OAuth 2.0](protocols-overview.md) or [OpenID Connect](protocols-overview.md). This article describes the types of applications that you can build, independent of the language or platform you prefer. It also helps you understand the high-level scenarios before you start building applications.
 
 Every application that uses Azure AD B2C must be registered in your [Azure AD B2C tenant](tutorial-create-tenant.md) by using the [Azure portal](https://portal.azure.com/). The application registration process collects and assigns values, such as:
@@ -71,6 +71,26 @@ To see this scenario in action, try one of the web application sign-in code samp
 
 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).
 
+## Single-page applications
+Many modern web applications are built as client-side single-page applications ("SPAs"). Developers write them by using JavaScript or a SPA framework such as Angular, Vue, and React. These applications run on a web browser and have different authentication characteristics than traditional server-side web applications.
+
+Azure AD B2C provides **two** options to enable single-page applications to sign in users and get tokens to access back-end services or web APIs:
+
+### Authorization code flow (with PKCE)
+- [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md). The authorization code flow allows the application to exchange an authorization code for **ID** tokens to represent the authenticated user and **Access** tokens needed to call protected APIs. In addition, it returns **Refresh** tokens that provide long-term access to resources on behalf of users without requiring interaction with those users. 
+
+This is the **recommended** approach. Having limited-lifetime refresh tokens helps your application adapt to [modern browser cookie privacy limitations](../active-directory/develop/reference-third-party-cookies-spas.md), like Safari ITP.
+
+To take advantage of this flow, your application can use an authentication library that supports it, like [MSAL.js 2.x](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser).
+
+<!-- ![Single-page applications-auth](./media/tutorial-single-page-app/spa-app-auth.svg) -->
+![Single-page applications-auth](./media/tutorial-single-page-app/active-directory-oauth-code-spa.png)
+
+### Implicit grant flow
+- [OAuth 2.0 implicit flow](implicit-flow-single-page-application.md). Some frameworks, like [MSAL.js 1.x](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-core), only support the implicit grant flow. The implicit grant flow allows the application to get **ID** and **Access** tokens. Unlike the authorization code flow, implicit grant flow does not return a **Refresh token**. 
+
+This authentication flow does not include application scenarios that use cross-platform JavaScript frameworks such as Electron and React-Native. Those scenarios require further capabilities for interaction with the native platforms.
+
 ## Web APIs
 
 You can use Azure AD B2C to secure web services such as your application's RESTful web API. Web APIs can use OAuth 2.0 to secure their data, by authenticating incoming HTTP requests using tokens. The caller of a web API appends a token in the authorization header of an HTTP request:
@@ -81,7 +101,7 @@ Host: www.mywebapi.com
 Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6...
 Accept: application/json
 ...
-```
+``` 
 
 The web API can then use the token to verify the API caller's identity and to extract information about the caller from claims that are encoded in the token. Learn more about the types of tokens and claims available to an app in the [Azure AD B2C token reference](tokens-overview.md).