Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into labssecurerdgateway

Author: spelluru

.openpublishing.redirection.json

@@ -3430,6 +3430,11 @@
       "redirect_url": "/azure/azure-resource-manager/resource-group-authenticate-service-principal",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/active-directory/develop/msal-testing.md",
+      "redirect_url": "/azure/active-directory/develop/msal-overview",
+      "redirect_document_id": true
+    },
     {
       "source_path": "articles/azure-resource-manager/resource-group-authenticate-service-principal.md",
       "redirect_url": "/azure/active-directory/develop/howto-authenticate-service-principal-powershell",
@@ -39552,6 +39557,11 @@
       "source_path": "articles/active-directory-domain-services/active-directory-ds-troubleshooting.md",
       "redirect_url": "/azure/active-directory-domain-services/troubleshoot",
       "redirect_document_id": false
-    }    
+    },
+    {
+      "source_path": "articles/backup/backup-azure-upgrade-backup-to-recovery-services.md",
+      "redirect_url": "/azure/backup/backup-create-rs-vault",
+      "redirect_document_id": true
+    }   
   ]
 }

articles/active-directory/develop/TOC.yml

@@ -228,9 +228,7 @@
           - name: Initialize applications (JS)
             href: msal-js-initializing-client-applications.md
         - name: Handle errors and exceptions
-          href: msal-handling-exceptions.md
-        - name: Test MSAL applications
-          href: msal-testing.md
+          href: msal-handling-exceptions.md        
         - name: Logging
           href: msal-logging.md
         - name: Single sign-on (JS)
@@ -366,6 +364,12 @@
               href: msal-net-user-gets-consent-for-multiple-resources.md
             - name: Provide your own HttpClient
               href: msal-net-provide-httpclient.md
+        - name: MSAL.js
+          items:
+            - name: Avoid page reloads
+              href: msal-js-avoid-page-reloads.md
+            - name: Pass custom state in authentication requests
+              href:  msal-js-pass-custom-state-authentication-request.md
     - name: Work with Visual Studio
       items:
       - name: Use the Active Directory connected service

articles/active-directory/develop/active-directory-v2-protocols.md

@@ -14,7 +14,7 @@ ms.workload: identity
 ms.tgt_pltfrm: na
 ms.devlang: na
 ms.topic: article
-ms.date: 04/11/2019
+ms.date: 05/30/2019
 ms.author: ryanwi
 ms.reviewer: hirsin
 ms.custom: aaddev
@@ -44,7 +44,7 @@ In nearly all OAuth 2.0 and OpenID Connect flows, there are four parties involve
 Every app that wants to accept both personal and work or school accounts must be registered through the **App registrations** experience in the [Azure portal](https://aka.ms/appregistrations) before it can sign these users in using OAuth 2.0 or OpenID Connect. The app registration process will collect and assign a few values to your app:
 
 * An **Application ID** that uniquely identifies your app
-* A **Redirect URI** or **Package Identifier** that can be used to direct responses back to your app
+* A **Redirect URI** (optional) that can be used to direct responses back to your app
 * A few other scenario-specific values.
 
 For more details, learn how to [register an app](quickstart-register-app.md).

articles/active-directory/develop/msal-client-application-configuration.md

@@ -17,37 +17,37 @@ ms.date: 04/25/2019
 ms.author: ryanwi
 ms.reviewer: saeeda
 ms.custom: aaddev
-#Customer intent: As an application developer, I want to learn about the types of client application so I can decide if this platform meets my application development needs and requirements.
+#Customer intent: As an application developer, I want to learn about the types of client apps so I can decide if this platform meets my app development requirements.
 ms.collection: M365-identity-device-management
 ---
 
 # Public client and confidential client applications
-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.  In contrast, Azure AD Authentication Library (ADAL) has the concept of authentication context (which is a connection to Azure AD).
+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. In contrast, Azure AD Authentication Library (ADAL) uses what's called *authentication context* (which is a connection to Azure AD).
 
-- **Confidential client applications** are applications, which run on servers (Web Apps, Web API, or even service/daemon applications). They are considered difficult to access, and therefore capable of keeping an application secret. Confidential clients are able to hold configuration time secrets. Each instance of the client has a distinct configuration (including clientId and 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 (web apps, Web API apps, or even service/daemon apps). They're considered difficult to access, and for that reason capable of keeping 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: <BR>
     ![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 applications, which run on devices or desktop machines or in a web browser. They are not trusted to safely keep application secrets, and therefore only access Web APIs on behalf of the user (they only support public client flows). Public clients are unable to hold configuration time secrets, and as a result have no client secret.
+- **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: <BR>
+    Public client apps: <BR>
     ![Desktop app](media/msal-client-applications/desktop-app.png) ![Browserless API](media/msal-client-applications/browserless-app.png) ![Mobile app](media/msal-client-applications/mobile-app.png)
 
 > [!NOTE]
-> In MSAL.js, there is no separation of public and confidential client apps.  MSAL.js represents client apps as user-agent-based apps, a public client in which the client code is executed in a user-agent such as a web browser.  These clients do not store secrets, since the browser context is openly accessible.
+> In MSAL.js, there is no separation of public and confidential client apps.  MSAL.js represents client apps as user agent-based apps, public clients in which the client code is executed in a user agent like a web browser. These clients don't store secrets because the browser context is openly accessible.
 
 ## Comparing the client types
-There are some commonalities and differences between public client and confidential client applications:
+Here are some similarities and differences between public client and confidential client apps:
 
-- Both kinds of applications maintain a user token cache and can acquire a token silently (in cases where the token is already in the token cache). Confidential client applications also have an app token cache for tokens, which are for the app itself.
-- Both manage user accounts and can get the accounts from the user token cache, get an account from its identifier, or remove an account.
-- Public client applications have four ways of acquiring a token (four authentication flows), whereas confidential client applications have three (and one method to compute the URL of the identity provider authorize endpoint). For more information, see Scenarios and Acquiring tokens.
+- 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 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).
 
-If you used ADAL in the past, you might notice that, contrary to ADAL's authentication context, in MSAL the client ID (also named application ID or app ID) is passed once at the construction of the application, and no longer needs to be repeated when acquiring a token. This is the case both for public and confidential client applications. Constructors of confidential client applications are also passed client credentials: the secret they share with the identity provider.
+If you've used ADAL, you might notice that, unlike ADAL's authentication context, 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 for 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
 Learn about:
 - [Client application configuration options](msal-client-application-configuration.md)
-- [Instantiating client applications using MSAL.NET](msal-net-initializing-client-applications.md).
-- [Instantiating client applications using MSAL.js](msal-js-initializing-client-applications.md).
+- [Instantiating client applications by using MSAL.NET](msal-net-initializing-client-applications.md)
+- [Instantiating client applications by using MSAL.js](msal-js-initializing-client-applications.md)

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

@@ -0,0 +1,150 @@
+---
+title: Avoid page reloads (Microsoft Authentication Library for JavaScript) | Azure
+description: Learn how to avoid page reloads when acquiring and renewing tokens silently using the Microsoft Authentication Library for JavaScript (MSAL.js).
+services: active-directory
+documentationcenter: dev-center-name
+author: rwike77
+manager: CelesteDG
+editor: ''
+
+ms.service: active-directory
+ms.subservice: develop
+ms.devlang: na
+ms.topic: conceptual
+ms.tgt_pltfrm: na
+ms.workload: identity
+ms.date: 05/29/2019
+ms.author: nacanuma
+ms.reviewer: saeeda
+ms.custom: aaddev
+#Customer intent: As an application developer, I want to learn about avoiding page reloads so I can create more robust applications.
+ms.collection: M365-identity-device-management
+---
+
+# Avoid page reloads when acquiring and renewing tokens silently using MSAL.js
+Microsoft Authentication Library for JavaScript (MSAL.js) uses hidden `iframe` elements to acquire and renew tokens silently in the background. Azure AD returns the token back to the registered redirect_uri specified in the token request(by default this is the app's root page). Since the response is a 302, it results in the HTML corresponding to the `redirect_uri` getting loaded in the `iframe`. Usually the app's `redirect_uri` is the root page and this causes it to reload.
+
+In other cases, if navigating to the app's root page requires authentication, it might lead to nested `iframe` elements or `X-Frame-Options: deny` error.
+
+Since MSAL.js cannot dismiss the 302 issued by Azure AD and is required to process the returned token, it cannot prevent the `redirect_uri` from getting loaded in the `iframe`.
+
+To avoid the entire app reloading again or other errors caused due to this, please follow these workarounds.
+
+## Specify different HTML for the iframe
+
+Set the `redirect_uri` property on config to a simple page, that does not require authentication. You have to make sure that it matches with the `redirect_uri` registered in Azure portal. This will not affect user's login experience as MSAL saves the start page when user begins the login process and redirects back to the exact location after login is completed.
+
+## Initialization in your main app file
+
+If your app is structured such that there is one central Javascript file that defines the app's initialization, routing, and other stuff, you can conditionally load your app modules based on whether the app is loading in an `iframe` or not. For example:
+
+In AngularJS: app.js
+
+```javascript
+// Check that the window is an iframe and not popup
+if (window !== window.parent && !window.opener) {
+angular.module('todoApp', ['ui.router', 'MsalAngular'])
+    .config(['$httpProvider', 'msalAuthenticationServiceProvider','$locationProvider', function ($httpProvider, msalProvider,$locationProvider) {
+        msalProvider.init(
+            // msal configuration
+        );
+
+        $locationProvider.html5Mode(false).hashPrefix('');
+    }]);
+}
+else {
+    angular.module('todoApp', ['ui.router', 'MsalAngular'])
+        .config(['$stateProvider', '$httpProvider', 'msalAuthenticationServiceProvider', '$locationProvider', function ($stateProvider, $httpProvider, msalProvider, $locationProvider) {
+            $stateProvider.state("Home", {
+                url: '/Home',
+                controller: "homeCtrl",
+                templateUrl: "/App/Views/Home.html",
+            }).state("TodoList", {
+                url: '/TodoList',
+                controller: "todoListCtrl",
+                templateUrl: "/App/Views/TodoList.html",
+                requireLogin: true
+            })
+
+            $locationProvider.html5Mode(false).hashPrefix('');
+
+            msalProvider.init(
+                // msal configuration
+            );
+        }]);
+}
+```
+
+In Angular: app.module.ts
+
+```javascript
+// Imports...
+@NgModule({
+  declarations: [
+    AppComponent,
+    MsalComponent,
+    MainMenuComponent,
+    AccountMenuComponent,
+    OsNavComponent
+  ],
+  imports: [
+    BrowserModule,
+    AppRoutingModule,
+    HttpClientModule,
+    ServiceWorkerModule.register('ngsw-worker.js', { enabled: environment.production }),
+    MsalModule.forRoot(environment.MsalConfig),
+    SuiModule,
+    PagesModule
+  ],
+  providers: [
+    HttpServiceHelper,
+    {provide: HTTP_INTERCEPTORS, useClass: MsalInterceptor, multi: true},
+    AuthService
+  ],
+  entryComponents: [
+    AppComponent,
+    MsalComponent
+  ]
+})
+export class AppModule {
+  constructor() {
+    console.log('APP Module Constructor!');
+  }
+
+  ngDoBootstrap(ref: ApplicationRef) {
+    if (window !== window.parent && !window.opener)
+    {
+      console.log("Bootstrap: MSAL");
+      ref.bootstrap(MsalComponent);
+    }
+    else
+    {
+    //this.router.resetConfig(RouterModule);
+      console.log("Bootstrap: App");
+      ref.bootstrap(AppComponent);
+    }
+  }
+}
+```
+
+MsalComponent:
+
+```javascript
+import { Component} from '@angular/core';
+import { MsalService } from '@azure/msal-angular';
+
+// This component is used only to avoid Angular reload
+// when doing acquireTokenSilent()
+
+@Component({
+  selector: 'app-root',
+  template: '',
+})
+export class MsalComponent {
+  constructor(private Msal: MsalService) {
+  }
+}
+```
+
+## Next steps
+Learn more about [building a single-page application (SPA)](scenario-spa-overview.md) using MSAL.js.

articles/active-directory/develop/msal-js-avoid-page-reloads.md

@@ -0,0 +1,73 @@
+---
+title: Pass custom state in authentication requests (Microsoft Authentication Library for JavaScript) | Azure
+description: Learn how to pass a custom state parameter value in authentication request using the Microsoft Authentication Library for JavaScript (MSAL.js).
+services: active-directory
+documentationcenter: dev-center-name
+author: rwike77
+manager: CelesteDG
+editor: ''
+
+ms.service: active-directory
+ms.subservice: develop
+ms.devlang: na
+ms.topic: conceptual
+ms.tgt_pltfrm: na
+ms.workload: identity
+ms.date: 05/29/2019
+ms.author: nacanuma
+ms.reviewer: saeeda
+ms.custom: aaddev
+#Customer intent: As an application developer, I want to learn about passing custom state in authentication requests so I can create more robust applications.
+ms.collection: M365-identity-device-management
+---
+
+# Pass custom state in authentication requests using MSAL.js
+The *state* parameter, as defined by OAuth 2.0, is included in an authentication request and is also returned in the token response to prevent cross-site request forgery attacks. By default, Microsoft Authentication Library for JavaScript (MSAL.js) passes a randomly generated unique *state* parameter value in the authentication requests.
+
+The state parameter can also be used to encode information of the app's state before redirect. You can pass the user's state in the app, such as the page or view they were on, as input to this parameter. The MSAL.js library allows you to pass your custom state as state parameter in the `Request` object:
+
+```javascript
+// Request type
+export type AuthenticationParameters = {
+    scopes?: Array<string>;
+    extraScopesToConsent?: Array<string>;
+    prompt?: string;
+    extraQueryParameters?: QPDict;
+    claimsRequest?: string;
+    authority?: string;
+    state?: string;
+    correlationId?: string;
+    account?: Account;
+    sid?: string;
+    loginHint?: string;
+};
+```
+
+For example:
+
+```javascript
+let loginRequest = {
+    scopes: ["user.read", "user.write"],
+    state: “page_url”
+}
+
+myMSALObj.loginPopup(loginRequest);
+```
+
+The passed in state is appended to the unique GUID set by MSAL.js when sending the request. When the response is returned, MSAL.js checks for a state match and then returns the custom passed in state in the `Response` object as `accountState`.
+
+```javascript
+export type AuthResponse = {
+    uniqueId: string;
+    tenantId: string;
+    tokenType: string;
+    idToken: IdToken;
+    accessToken: string;
+    scopes: Array<string>;
+    expiresOn: Date;
+    account: Account;
+    accountState: string;
+};
+```
+
+To learn more, read about [building a single-page application (SPA)](scenario-spa-overview.md) using MSAL.js.