1.4.0 Release Branch

change/msal-2020-08-10-11-48-42-scopes-and-response-types.json

@@ -0,0 +1,8 @@
+{
+  "type": "minor",
+  "comment": "Enables idToken acquisition in acquireToken API calls through the use of OIDC scopes by redefining the way response_type is determined. (PR #2022)",
+  "packageName": "msal",
+  "email": "[email protected]",
+  "dependentChangeType": "patch",
+  "date": "2020-08-10T18:48:42.205Z"
+}

change/msal-2020-08-12-11-09-30-msal-core-adfs.json

@@ -0,0 +1,8 @@
+{
+  "type": "minor",
+  "comment": "ADFS 2019 Support (#1668)",
+  "packageName": "msal",
+  "email": "[email protected]",
+  "dependentChangeType": "patch",
+  "date": "2020-08-12T18:09:30.073Z"
+}

change/msal-2020-08-12-14-47-04-b2c-multiple-policies.json

@@ -0,0 +1,8 @@
+{
+  "type": "minor",
+  "comment": "B2C Multiple Policy Support (#1757)",
+  "packageName": "msal",
+  "email": "[email protected]",
+  "dependentChangeType": "patch",
+  "date": "2020-08-12T21:47:04.427Z"
+}

lib/msal-core/README.md

@@ -19,48 +19,48 @@ MSAL for JavaScript enables client-side JavaScript web applications, running in
 
 #### Latest compiled and minified JavaScript (US West region)
 ```html
-<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.3.4/js/msal.js"></script>
+<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.4.0/js/msal.js"></script>
 ```
 ```html
-<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.3.4/js/msal.min.js"></script>
+<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.4.0/js/msal.min.js"></script>
 ````
 
 #### Alternate region URLs (Europe region)
 ```html
-<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.3.4/js/msal.js"></script>
+<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.4.0/js/msal.js"></script>
 ```
 ```html
-<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.3.4/js/msal.min.js"></script>
+<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.4.0/js/msal.min.js"></script>
 ```
 
 ### Via Latest Microsoft CDN Version (with SRI Hash):
 
 #### Latest compiled and minified JavaScript
 
 ```html
-<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.3.4/js/msal.js" integrity="sha384-SLUfcZqOuUn4mgjkztK5Q6sZ/m08tFoo6K1sSGPkKN+y+QZZZ4DYFNpLmLcmMoLA" crossorigin="anonymous"></script>
+<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.4.0/js/msal.js" integrity="sha384-JUS68ZBO4b1j6ODn7kQpZo+5aaopc61YDBiG3LNzQu/9sMXhjcJW6fjIM1Y4uy3X" crossorigin="anonymous"></script>
 ```
 ```html
-<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.3.4/js/msal.min.js" integrity="sha384-pkCsjTAwVvsQv5UEAo+kNmnVMFs/GoqIP/G9J0ZV7rC55j3hcV225SGGQJY8wwtn" crossorigin="anonymous"></script>
+<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.4.0/js/msal.min.js" integrity="sha384-2D8uXeS7ZdB2Bn3guhdPcT51gdZYtzSK2xRnWF+w0sOfN1zuWRu/0LQRyqk1YBdW" crossorigin="anonymous"></script>
 ```
 
 #### Alternate region URLs
 
 To help ensure reliability, Microsoft provides a second CDN:
 
 ```html
-<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.3.4/js/msal.js" integrity="sha384-SLUfcZqOuUn4mgjkztK5Q6sZ/m08tFoo6K1sSGPkKN+y+QZZZ4DYFNpLmLcmMoLA" crossorigin="anonymous"></script>
+<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.4.0/js/msal.js" integrity="sha384-JUS68ZBO4b1j6ODn7kQpZo+5aaopc61YDBiG3LNzQu/9sMXhjcJW6fjIM1Y4uy3X" crossorigin="anonymous"></script>
 ```
 ```html
-<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.3.4/js/msal.min.js" integrity="sha384-pkCsjTAwVvsQv5UEAo+kNmnVMFs/GoqIP/G9J0ZV7rC55j3hcV225SGGQJY8wwtn" crossorigin="anonymous"></script>
+<script type="text/javascript" src="https://alcdn.msftauth.net/lib/1.4.0/js/msal.min.js" integrity="sha384-2D8uXeS7ZdB2Bn3guhdPcT51gdZYtzSK2xRnWF+w0sOfN1zuWRu/0LQRyqk1YBdW" crossorigin="anonymous"></script>
 ```
 
 Below is an example of how to use one CDN as a fallback when the other CDN is not working:
 
 ```html
-<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.3.4/js/msal.js"></script>
+<script type="text/javascript" src="https://alcdn.msauth.net/lib/1.4.0/js/msal.js"></script>
 <script type="text/javascript">
-    if(typeof Msal === 'undefined')document.write(unescape("%3Cscript src='https://alcdn.msftauth.net/lib/1.3.4/js/msal.js' type='text/javascript' %3E%3C/script%3E"));
+    if(typeof Msal === 'undefined')document.write(unescape("%3Cscript src='https://alcdn.msftauth.net/lib/1.4.0/js/msal.js' type='text/javascript' %3E%3C/script%3E"));
 </script>
 ```
 

lib/msal-core/docs/FAQ.md

@@ -51,6 +51,7 @@
 **[Common Issues](#common-issues)**
 1. [How to avoid page reloads when acquiring and renewing tokens silently?](#how-to-avoid-page-reloads-when-acquiring-and-renewing-tokens-silently)
 1. [Why is my application stuck in an infinite redirect loop?](#why-is-my-application-stuck-in-an-infinite-redirect-loop)
+1. [I'm using one of your samples on Internet Explorer and I get the error SignIn() is not defined](#im-using-one-of-your-samples-on-internet-explorer-and-i-get-the-error-signin-is-not-defined)
 1. [Why is MSAL throwing an error?](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-core/docs/errors.md)
 
 ***
@@ -346,25 +347,25 @@ Please see the documentation on [Tenancy in Azure Active Directory](https://docs
 
 ## My B2C application has more than one user-flow/policy. How do I work with multiple policies in MSAL.js?
 
-Unfortunately, MSAL.js does not support multiple B2C policies _out-of-the-box_ at this moment. Nevertheless, you can still utilize the library to workaround this limitation. For instance, review our sample [here](https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp) to see how to implement **sign-up/sign-in** and **password reset** user flows.
+MSAL.js allows you to provide an authority on a per-request basis. To acquire an access token for a different policy than the one you signed in with, simply pass the relevant authority as a part of the request object.
 
-## How can I implement password reset user flow in my B2C application with MSAL.js?
+```javascript
+const request = {
+scopes: ["https://b2ctenant.onmicrosoft.com/exampleApi/exampleScope"],
+authority: "https://b2ctenant.b2clogin.com/b2ctenant.onmicrosoft.com/examplePolicy"
+}
 
-Please review our sample [here](https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp) to see how to implement the **password reset** user flow.
+msal.acquireTokenPopup(request);
+```
 
-## I'm using one of your samples on Internet Explorer and I get the error "SignIn() is not defined"
+A few additional things to keep in mind regarding multiple policy scenarios:
 
-Our samples use [ES6](http://www.ecma-international.org/ecma-262/6.0/) conventions, in particular **promises**, **arrow functions** and **template literals**. As such, they will **not** work on Internet Explorer out-of-the-box. For **promises**, you need to add a polyfill, i.e.:
+- MSAL.js 1.x is only able to cache one id_token at a time, which means that obtaining an id_token for a different policy will overwrite the cached id_token from the previous policy.
+- Some policies, such as profile_edit and password_reset, require interaction and cannot be used to renew tokens silently. Obtaining a cached access token via `acquireTokenSilent` is still possible, however, if the token is expired the service will throw an "X-Frame Options DENY" error when MSAL attempts to renew it. When this happens your application must catch this error and fallback to calling an interactive method (`acquireTokenRedirect` or `acquireTokenPopup`)
 
-```html
-<head>
-   <!-- adding pollyfil for promises on IE11  -->
-      <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/js-polyfills/0.1.42/polyfill.min.js"> 
-   </script>
-</head>
-```
+## How can I implement password reset user flow in my B2C application with MSAL.js?
 
-For **arrow functions** and **template literals**, you need to transpile them to old JavaScript. You can use [this tool](https://babeljs.io/repl) to help with the process.
+Please checkout our sample [here](https://github.com/Azure-Samples/active-directory-b2c-javascript-msal-singlepageapp) to see how to implement the **password reset** user flow.
 
 # Common Issues
 
@@ -534,3 +535,17 @@ msal = new Msal.UserAgentApplication({
     }
 })
 ```
+
+## I'm using one of your samples on Internet Explorer and I get the error "SignIn() is not defined"
+
+Our samples use [ES6](http://www.ecma-international.org/ecma-262/6.0/) conventions, in particular **promises**, **arrow functions** and **template literals**. As such, they will **not** work on Internet Explorer out-of-the-box. For **promises**, you need to add a polyfill, i.e.:
+
+```html
+<head>
+   <!-- adding pollyfil for promises on IE11  -->
+      <script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/js-polyfills/0.1.42/polyfill.min.js"> 
+   </script>
+</head>
+```
+
+For **arrow functions** and **template literals**, you need to transpile them to old JavaScript. You can use [this tool](https://babeljs.io/repl) to help with the process.

lib/msal-core/docs/response-types.md

@@ -0,0 +1,85 @@
+# Response Types
+
+> :warning: This document only applies to `[email protected]` which implements the Implicit Flow Grant type. For the Authorization Code Flow Grant type, please use the [msal-browser](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser) library.
+
+## Quick Reference
+
+> This section provides a summary of the main points this document addresses, without getting into any details. If you need more clarity or information about the functionality and behavior of Response Types in `[email protected]`, please read the rest of this document.
+
+The key takeaways of the way `[email protected]` determines and handles `Response Types` are:
+
+1. `loginRedirect`, `loginPopup` and `ssoSilent` will always return ID tokens and have a `response_type` of `id_token`.
+2. `acquireToken` requests will always return an ID token if `openid` or `profile` are included in the request scopes.
+3. `acquireToken` requests will always return an access token if a `resource scope` is requested.
+
+If you're interested in learning more about the reasoning and implications around the way response types are determined and what they are used for, please read the rest of this document.
+
+## Definition and Types
+The `[email protected]` library, in compliance of both the OAuth 2.0 protocol specification as well as the OpenID Connect specification, defines and supports three different `response types`:
+
+* token
+* id_token
+* id_token token
+
+The **`[email protected]` library does not support the `code` response type because it does not implement the Authorization Code grant. If you are looking to implement the Authorization Code grant type, consider the [msal-browser](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser) library.**
+
+The listed response types are possible values for the `response_type` parameter in OAuth 2.0 HTTP requests. Assuming a valid request, this parameter determines what kind of token is sent back by the Secure Token Service (STS) that `[email protected]` requests access and ID tokens from.
+
+| Response Type | Specification that defines it | Expected token type from successful request | Action |
+| ------------- | ----------------------------- | ------------------------------------------- | ------ |
+| `token` |[OAuth 2.0](https://tools.ietf.org/html/rfc6749#section-3.1.1) | Access Token | Authorization |
+| `id_token`| [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#Authentication) | ID Token | Authentication |
+|`id_token token`| [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html#Authentication) | Access Token and ID token | Authorization & Authentication |
+
+**Note: Given that `[email protected]` uses the OAuth 2.0 Implicit Flow exclusively, which leverages URL fragments for token reception, it is important to be mindful of URL length limitations. Browsers like IE impose restrictions on the length of URLs, so getting both an access token and ID token in the same URL may cause unexpected or incorrect behavior.**
+
+## Response Type configuration and behavior
+
+The `response_type` attribute presented above cannot be configured directly. However, it is important to understand the way `[email protected]` determines which response type is set and, therefore, what kind of token the developer can expect for each scenario. The factors that come into consideration when setting the request's `response_type` parameter are the following:
+
+1. The `[email protected]` API called
+2. Whether the account passed into the request configuration matches the account in the MSAL cache
+3. The contents of the `scopes` array in the Authorization Request Configuration object. For more information on `scopes` configuration, please consult the [Scopes](/docs/scopes.md) document.
+
+**Important note: Login APIs will always set `response_type=id_token`, given that they are designed to perform user login (authentication).**
+
+Login APIs include:
+
+* loginRedirect
+* loginPopup
+* ssoSilent
+
+In other words, whenever you call `loginRedirect` or `loginPopup` to sign a user in, you should expect to receive an ID token if the request is successful.
+
+The following section contains quick reference tables for both `login` and `acquireToken` APIs that accurately map the request configuration to the resulting response type.
+
+## Quick reference tables
+
+### Login APIs
+
+Applies to: `loginRedirect`, `loginPopup`, `ssoSilent`
+
+| Input scopes | Account passed in | Response Type Result |
+| ----------------- | ------------ | -------------------- |
+| Any case | Any case | `id_token`|
+
+### Acquire Token APIs
+
+Applies to: `acquireTokenRedirect`, `acquireTokenPopup`, `acquireTokenSilent`
+
+* *OIDC scopes: any combination of `openid` and/or `profile`*
+* *OIDC scopes only: Same as OIDC scopes but with no other scopes in the array*
+
+| Input scopes | Account passed in | Response Type Result |
+| ----------------- | ------------ | -------------------- |
+| ClientId as only scope | Any case | `id_token`|
+| OIDC scopes only | Any case | `id_token`|
+| ClientId with OIDC scopes | Any case | `id_token token` |
+| Resource scope(s) with OIDC scopes (technically the same as above) | Any case | `id_token token` |
+| Resource scope(s) only | Matches cached account object | `token` |
+| Resource scope(s) and ClientId | Matches cached account object | `token` |
+| Resource scope(s) only | Doesn't match cached account object | `id_token token` |
+
+**Note: As seen in the table above, when ClientId is not the only scope, it is assumed to be a resource scope with no special behavior.**
+
+