Merge branch 'dev' into tnorling-patch-1

Author: tnorling

change/@azure-msal-browser-0636e519-d5f4-4f3a-afa4-d22562ac1265.json

@@ -0,0 +1,7 @@
+{
+  "type": "none",
+  "comment": "resource-and-scopes doc correction",
+  "packageName": "@azure/msal-browser",
+  "email": "dogan.erisen@gmail.com",
+  "dependentChangeType": "none"
+}

lib/msal-browser/docs/resources-and-scopes.md

@@ -1,14 +1,15 @@
 # Resources and Scopes
 
 > :warning: Before you start here, make sure you understand how to [acquire and use an access token](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/acquire-token.md).
+
 Azure Active Directory v2.0 & Microsoft Identity Platform employs a *scope-centric* model to access resources. Here, a *resource* refers to any application that can be of recipient of an **Access Token** (such as [MS Graph API](https://docs.microsoft.com/graph/overview) or your own web API), and a *scope* (*aka* "permission") refers to any aspect of a resource that an **Access Token** grants rights.
 
 **Access Token** requests in **MSAL.js** are meant to be *per-resource-per-scope(s)*. This means that an **Access Token** requested for resource **A** with scope `scp1`:
 
 - cannot be used for accessing resource **A** with scope `scp2`, and,
 - cannot be used for accessing resource **B** of any scope.
 
-The intended recipient of an **Access Token** is represented by the `aud` claim; in case the value for the `aud` claim does not match the resource [APP ID URI](https://docs.microsoft.com/azure/active-directory/develop/scenario-protected-web-api-app-registration), the token should be considered invalid. Likewise, the permissions that an **Access Token** grants is represented by the `scp` claim. See [ Access Token claims](https://docs.microsoft.com/azure/active-directory/develop/access-tokens#payload-claims) for more information.
+The intended recipient of an **Access Token** is represented by the `aud` claim; in case the value for the `aud` claim does not match the resource [APP ID URI](https://docs.microsoft.com/azure/active-directory/develop/scenario-protected-web-api-app-registration), the token should be considered invalid. Likewise, the permissions that an **Access Token** grants is represented by the `scp` claim. See [Access Token claims](https://docs.microsoft.com/azure/active-directory/develop/access-tokens#payload-claims) for more information.
 
 ## Working with Multiple Resources
 
@@ -28,7 +29,7 @@ Bear in mind that you *can* request multiple scopes for the same resource (e.g.
 
  ```javascript
  const graphToken = await msalInstance.acquireTokenSilent({
-      scopes: [ "User.Read", "User.Write", "Calendar.Read"] // all MS Graph API scopes
+      scopes: [ "User.Read", "User.Write", "Calendar.Read" ] // all MS Graph API scopes
  });
  ```
 
@@ -59,13 +60,16 @@ In **Azure AD**, the scopes (*permissions*) set directly on the application regi
   msalInstance.acquireTokenSilent(tokenRequest);
  ```
 
-In the code snippet above, the user will be prompted for consent once they authenticate and receive an **ID Token** and an **Access Token** with scope `User.Read`. Later, if they request an **Access Token** for `User.Read`, they will not be asked for consent again (in other words, they can acquire a token *silently*). On the other hand, the user did not consented to `Mail.Read` at the authentication stage. As such, they will be asked for consent when requesting an **Access Token** for that scope. The token received will contain all the previously consented scopes, hence the term *incremental consent*.
+In the code snippet above, the user will be prompted for consent once they authenticate and receive an **ID Token** and an **Access Token** with the scope `User.Read`. Later, if they request an **Access Token** for `User.Read`, they will not be asked for consent again (in other words, they can acquire a token *silently*).
+
+On the other hand, the user did not consent to `Mail.Read` at the authentication stage, therefore, will be asked for consent when requesting an **Access Token** for `Mail.Read` scope. The token received will contain all the previously consented scopes (for that specific resource), hence the term *incremental consent*.
 
 Consider a slightly different case:
 
  ```javascript
   const loginRequest = {
-       scopes: [ "openid", "profile", "User.Read", "api://<myCustomApiClientId>/My.Scope" ]
+       scopes: [ "openid", "profile", "User.Read" ],
+       extraScopesToConsent: [ "api://<myCustomApiClientId>/My.Scope"]
   };
   const tokenRequest = {
        scopes: [ "Mail.Read" ]
@@ -75,9 +79,9 @@ Consider a slightly different case:
   }
   // will return an ID Token and an Access Token with scopes: "openid", "profile" and "User.Read"
   msalInstance.loginPopup(loginRequest);
-  // will fail and fallback to an interactive method prompting a consent screen
+  // will fail with InteractionRequiredError due to lack of consent for "Mail.Read" scope. You should fallback to an interactive method in this case.
   msalInstance.acquireTokenSilent(tokenRequest);
-  // will succeed and return an Access Token with scopes "openid", "profile", "User.Read" and "api://<myCustomApiClientId>/My.Scope"
+  // will succeed and return an Access Token with scope "api://<myCustomApiClientId>/My.Scope"
   msalInstance.acquireTokenSilent(anotherTokenRequest);
  ```
 

lib/msal-react/docs/getting-started.md

@@ -174,7 +174,7 @@ A hook that returns the `PublicClientApplication` instance, an array of all acco
 You can read more about this hook in the [hooks doc](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-react/docs/hooks.md#usemsal-hook).
 
 ```javascript
-import React from 'react'l
+import React from 'react';
 import { useMsal } from "@azure/msal-react";
 
 export function App() {