Merge pull request #224097 from MicrosoftDocs/main

Publish to live, Tuesday 4 AM PST, 1/17

Author: ttorble

articles/active-directory/develop/msal-client-applications.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 12/19/2021
+ms.date: 01/16/2023
 ms.author: cwerner
 ms.reviewer: saeeda
 ms.custom: aaddev, has-adal-ref, engagement-fy23
@@ -18,15 +18,15 @@ ms.custom: aaddev, has-adal-ref, engagement-fy23
 
 # Public client and confidential client applications
 
-The Microsoft Authentication Library (MSAL) defines two types of clients: public clients and confidential clients. The two client types are distinguished by their ability to authenticate securely with the authorization server and maintain the confidentiality of their client credentials. 
+The Microsoft Authentication Library (MSAL) defines two types of clients; public clients and confidential clients. The two client types are distinguished by the ability to authenticate securely with the authorization server and maintain the confidentiality of client credentials. 
 
-- **Confidential client applications** are apps that run on servers (web apps, web API apps, or even service/daemon apps). They're considered difficult to access, and for that reason can keep an application secret. Confidential clients can hold configuration-time secrets. Each instance of the client has a distinct configuration (including client ID and client secret). These values are difficult for end users to extract. A web app is the most common confidential client. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.
+- **Confidential client applications** are apps that run on servers, such as web apps, web API apps, or service/daemon apps. They're considered difficult to access, and for that reason can keep an application secret. Confidential clients can hold configuration-time secrets. Each instance of the client has a distinct configuration (including client ID and client secret). These values are difficult for end users to extract. A web app is the most common confidential client. The client ID is exposed through the web browser, but the secret is passed only in the back channel and never directly exposed.
 
   Confidential client apps: 
 
   ![Web app](media/msal-client-applications/web-app.png) ![Web API](media/msal-client-applications/web-api.png) ![Daemon/service](media/msal-client-applications/daemon-service.png)
 
-- **Public client applications** are apps that run on devices or desktop computers or in a web browser. They're not trusted to safely keep application secrets, so they only access web APIs on behalf of the user. (They support only public client flows.) Public clients can't hold configuration-time secrets, so they don't have client secrets.
+- **Public client applications** are apps that run on devices, desktop computers or in a web browser. They're not trusted to safely keep application secrets, so they only access web APIs on behalf of the user. They also only support public client flows. Public clients can't hold configuration-time secrets, so they cannot have client secrets.
 
   Public client apps: 
 
@@ -36,13 +36,13 @@ In MSAL.js, there's no separation of public and confidential client apps. MSAL.j
 
 ## Comparing the client types
 
-Here are some similarities and differences between public and confidential client apps:
+The following are some similarities and differences between public and confidential client apps:
 
-- Both kinds of app maintain a user token cache and can acquire a token silently (when the token is already in the token cache). Confidential client apps also have an app token cache for tokens that are for the app itself.
+- Both types of app maintain a user token cache and can acquire a token silently (when the token is already in the token cache). Confidential client apps also have an app token cache for tokens that are for the app itself.
 - Both types of app manage user accounts and can get an account from the user token cache, get an account from its identifier, or remove an account.
-- Public client apps have four ways to acquire a token (four authentication flows). Confidential client apps have three ways to acquire a token (and one way to compute the URL of the identity provider authorize endpoint). For more information, see [Acquiring tokens](msal-acquire-cache-tokens.md).
+- Public client apps have four ways to acquire a token, through four separate authentication flows. Confidential client apps have three ways to acquire a token and one way to compute the URL of the identity provider authorize endpoint. For more information, see [Acquiring tokens](msal-acquire-cache-tokens.md).
 
-In MSAL, the client ID (also called the _application ID_ or _app ID_) is passed once at the construction of the application. It doesn't need to be passed again when the app acquires a token. This is true for both public and confidential client apps. Constructors of confidential client apps are also passed client credentials: the secret they share with the identity provider.
+In MSAL, the client ID, also called the _application ID_ or _app ID_, is passed once at the construction of the application. It doesn't need to be passed again when the app acquires a token. This is true for both public and confidential client apps. Constructors of confidential client apps are also passed client credentials: the secret they share with the identity provider.
 
 ## Next steps
 

articles/active-directory/develop/msal-js-initializing-client-applications.md

@@ -9,18 +9,18 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/21/2021
+ms.date: 01/16/2023
 ms.author: owenrichards
 ms.reviewer: saeeda
-ms.custom: aaddev, devx-track-js
+ms.custom: aaddev, devx-track-js, engagement-fy23
 # Customer intent: As an application developer, I want to learn about initializing a client application in MSAL.js to enable support for authentication and authorization in a JavaScript single-page application (SPA).
 ---
 
 # Initialize client applications using MSAL.js
 
 This article describes initializing the Microsoft Authentication Library for JavaScript (MSAL.js) with an instance of a user-agent application.
 
-The user-agent application is a form of public client application in which the client code is executed in a user-agent such as a web browser. Such clients don't store secrets because the browser context is openly accessible.
+The user-agent application is a form of public client application in which the client code is executed in a user-agent such as a web browser. Clients such as these don't store secrets because the browser context is openly accessible.
 
 To learn more about the client application types and application configuration options, see [Public and confidential client apps in MSAL](msal-client-applications.md).
 
@@ -39,18 +39,18 @@ After registering your app, you'll need some or all of the following values that
 
 ## Initialize MSAL.js 2.x apps
 
-Initialize the MSAL.js authentication context by instantiating a [PublicClientApplication][msal-js-publicclientapplication] with a [Configuration][msal-js-configuration] object. The minimum required configuration property is the `clientID` of your application, shown as the **Application (client) ID** on the **Overview** page of the app registration in the Azure portal.
+Initialize the MSAL.js authentication context by instantiating a [PublicClientApplication][msal-js-publicclientapplication] with a [Configuration][msal-js-configuration] object. The minimum required configuration property is the `clientID` of the application, shown as **Application (client) ID** on the **Overview** page of the app registration in the Azure portal.
 
 Here's an example configuration object and instantiation of a `PublicClientApplication`:
 
 ```javascript
 const msalConfig = {
   auth: {
-    clientId: "11111111-1111-1111-111111111111",
-    authority: "https://login.microsoftonline.com/common",
+    clientId: "Enter_the_Application_Id_Here",
+    authority: "https://login.microsoftonline.com/Enter_the_Tenant_Info_Here",
     knownAuthorities: [],
-    redirectUri: "https://localhost:3001",
-    postLogoutRedirectUri: "https://localhost:3001/logout",
+    redirectUri: "https://localhost:{port}/redirect",
+    postLogoutRedirectUri: "https://localhost:{port}/redirect",
     navigateToLoginRequestUrl: true,
   },
   cache: {
@@ -106,25 +106,25 @@ msalInstance
 
 ### `handleRedirectPromise`
 
-Invoke [handleRedirectPromise][msal-js-handleredirectpromise] when your application uses the redirect flows. When using the redirect flows, `handleRedirectPromise` should be run on every page load.
+Invoke [handleRedirectPromise][msal-js-handleredirectpromise] when the application uses redirect flows. When using redirect flows, `handleRedirectPromise` should be run on every page load.
 
-There are three possible outcomes from the promise:
+Three outcomes are possible from the promise:
 
 - `.then` is invoked and `tokenResponse` is truthy: The application is returning from a redirect operation that was successful.
 - `.then` is invoked and `tokenResponse` is falsy (`null`): The application isn't returning from a redirect operation.
 - `.catch` is invoked: The application is returning from a redirect operation and there was an error.
 
 ## Initialize MSAL.js 1.x apps
 
-Initialize the MSAL 1.x authentication context by instantiating a [UserAgentApplication][msal-js-useragentapplication] with a configuration object. The minimum required configuration property is the `clientID` of your application, shown as the **Application (client) ID** on the **Overview** page of the app registration in the Azure portal.
+Initialize the MSAL 1.x authentication context by instantiating a [UserAgentApplication][msal-js-useragentapplication] with a configuration object. The minimum required configuration property is the `clientID` of your application, shown as **Application (client) ID** on the **Overview** page of the app registration in the Azure portal.
 
 For authentication methods with redirect flows ([loginRedirect][msal-js-loginredirect] and [acquireTokenRedirect][msal-js-acquiretokenredirect]) in MSAL.js 1.2.x or earlier, you must explicitly register a callback for success or error through the `handleRedirectCallback()` method. Explicitly registering the callback is required in MSAL.js 1.2.x and earlier because redirect flows don't return promises like the methods with a pop-up experience do. Registering the callback is _optional_ in MSAL.js version 1.3.x and later.
 
 ```javascript
 // Configuration object constructed
 const msalConfig = {
   auth: {
-    clientId: "11111111-1111-1111-111111111111",
+    clientId: "Enter_the_Application_Id_Here",
   },
 };
 
@@ -145,7 +145,7 @@ msalInstance.handleRedirectCallback(authCallback);
 
 Both MSAL.js 1.x and 2.x are designed to have a single instance and configuration of the `UserAgentApplication` or `PublicClientApplication`, respectively, to represent a single authentication context.
 
-Multiple instances of `UserAgentApplication` or `PublicClientApplication` aren't recommended as they cause conflicting cache entries and behavior in the browser.
+Multiple instances of `UserAgentApplication` or `PublicClientApplication` aren't recommended as they can cause conflicting cache entries and behavior in the browser.
 
 ## Next steps
 

articles/active-directory/develop/msal-js-sso.md

@@ -9,22 +9,22 @@ ms.service: active-directory
 ms.subservice: develop
 ms.topic: conceptual
 ms.workload: identity
-ms.date: 10/25/2021
+ms.date: 01/16/2023
 ms.author: owenrichards
 ms.reviewer: saeeda
-ms.custom: aaddev, has-adal-ref
+ms.custom: aaddev, has-adal-ref, engagement-fy23
 #Customer intent: As an application developer, I want to learn about enabling single sign on experiences with MSAL.js library so I can decide if this platform meets my application development needs and requirements.
 ---
 
 # Single sign-on with MSAL.js
 
-Single sign-on (SSO) provides a more seamless experience by reducing the number of times your users are asked for their credentials. Users enter their credentials once, and the established session can be reused by other applications on the device without further prompting.
+Single sign-on (SSO) provides a more seamless experience by reducing the number of times a user is asked for credentials. Users enter their credentials once, and the established session can be reused by other applications on the same device without further prompting.
 
-Azure Active Directory (Azure AD) enables SSO by setting a session cookie when a user authenticates for the first time. MSAL.js also caches the ID tokens and access tokens of the user in the browser storage per application domain. These two mechanisms (i.e. Azure AD session cookie and MSAL cache) are independent of each other, but works together to provide SSO behavior.
+Azure Active Directory (Azure AD) enables SSO by setting a session cookie when a user authenticates for the first time. MSAL.js also caches the ID tokens and access tokens of the user in the browser storage per application domain. The two mechanisms, Azure AD session cookie and Microsoft Authentication Library (MSAL) cache, are independent of each other but work together to provide SSO behavior.
 
 ## SSO between browser tabs for the same app
 
-When a user has your application open in several tabs and signs in on one of them, they can be signed into the same app open on the other tabs without being prompted. To do so, you'll need to set the *cacheLocation* in MSAL.js configuration object to `localStorage` as shown below.
+When a user has an application open in several tabs and signs in on one of them, they can be signed into the same app open on other tabs without being prompted. To do so, you'll need to set the *cacheLocation* in MSAL.js configuration object to `localStorage` as shown in the following example:
 
 ```javascript
 const config = {
@@ -43,7 +43,7 @@ In this case, application instances in different browser tabs make use of the sa
 
 ## SSO between different apps
 
-When a user authenticates, a session cookie is set on the Azure AD domain in the browser. MSAL.js relies on this session cookie to provide SSO for the user between different applications. In particular, MSAL.js offers the `ssoSilent` method to sign-in the user and obtain tokens without an interaction. However, if the user has multiple user accounts in a session with Azure AD, then the user is prompted to pick an account to sign in with. As such, there are two ways to achieve SSO using `ssoSilent` method.
+When a user authenticates, a session cookie is set on the Azure AD domain in the browser. MSAL.js relies on this session cookie to provide SSO for the user between different applications. In particular, MSAL.js offers the `ssoSilent` method to sign-in the user and obtain tokens without an interaction. However, if the user has multiple user accounts in a session with Azure AD, they're then prompted to pick an account to sign in with. As such, there are two ways to achieve SSO using `ssoSilent` method.
 
 ### With user hint
 
@@ -136,7 +136,7 @@ try {
 
 ### Without user hint
 
-You can attempt to use the `ssoSilent` method without passing any `account`, `sid` or `login_hint` as shown in the code below:
+You can attempt to use the `ssoSilent` method without passing any `account`, `sid` or `login_hint` as shown in the following code:
 
 ```javascript
 const request = {
@@ -156,22 +156,22 @@ try {
 }
 ```
 
-However, there's a likelihood of silent sign-in errors if the application has multiple users in a single browser session or if the user has multiple accounts for that single browser session. You may see the following error in the case of multiple accounts:
+However, there's a likelihood of silent sign-in errors if the application has multiple users in a single browser session or if the user has multiple accounts for that single browser session. The following error may be displayed if multiple accounts are available:
 
 ```txt
 InteractionRequiredAuthError: interaction_required: AADSTS16000: Either multiple user identities are available for the current request or selected account is not supported for the scenario.
 ```
 
-The error indicates that the server couldn't determine which account to sign into, and will require either one of the parameters above (`account`, `login_hint`, `sid`) or an interactive sign-in to choose the account.
+The error indicates that the server couldn't determine which account to sign into, and will require either one of the parameters in the previous example (`account`, `login_hint`, `sid`) or an interactive sign-in to choose the account.
 
 ## Considerations when using `ssoSilent`
 
 ### Redirect URI (reply URL)
 
 For better performance and to help avoid issues, set the `redirectUri` to a blank page or other page that doesn't use MSAL.
 
-- If your application users only popup and silent methods, set the `redirectUri` on the `PublicClientApplication` configuration object.
-- If your application also uses redirect methods, set the `redirectUri` on a per-request basis.
+- If the application users only popup and silent methods, set the `redirectUri` on the `PublicClientApplication` configuration object.
+- If the application also uses redirect methods, set the `redirectUri` on a per-request basis.
 
 ### Third-party cookies
 
@@ -185,7 +185,7 @@ To resolve the error, the user must create an interactive authentication request
 
 ## Negating SSO with prompt=login
 
-If you like Azure AD to prompt the user for entering their credentials despite there being an active session with the authorization server, you can use the **login** prompt parameter in requests with MSAL.js. See [MSAL.js prompt behavior](msal-js-prompt-behavior.md) for more.
+If you prefer Azure AD to prompt the user for entering their credentials despite an active session with the authorization server, you can use the **login** prompt parameter in requests with MSAL.js. See [MSAL.js prompt behavior](msal-js-prompt-behavior.md) for more.
 
 ## Sharing authentication state between ADAL.js and MSAL.js