In-app ads

As of June 1, 2020, the Microsoft Ad Monetization platform for Windows UWP apps will be shut down. Learn more

Use the Monetize > In-app ads page in Partner Center to create and manage ad units for:

• Universal Windows Platform (UWP) apps that use the Microsoft Advertising SDK.
• Previously published Windows 8.x and Windows Phone 8.x apps that use the Microsoft Advertising SDK for Windows and Windows Phone 8.x.

You can no longer upload new XAP packages built using the Windows Phone 8.x SDK(s). Apps that are already in Store with XAP packages will continue to work on Windows 10 Mobile devices. For more info, see this blog post.

For more information about how to integrate these SDKs with your apps to display ads, see Display ads in your app with the Microsoft Advertising SDK.

Create ad units

To create an ad unit for a banner ad, interstitial ad, or native ad in your app:

Go to the Monetize > In-app ads page in Partner Center and click Create ad unit.

In the App name drop-down, select the app in which your ad unit will be used.

In the Ad unit name field, enter a name for the ad unit. This can be any descriptive string that you want to use to identify the ad unit for reporting purposes.

In the Ad unit type drop-down, select the ad type.

• If you are showing a banner ad in your app, select Banner.
• If you are showing an interstitial video ad or interstitial banner ad in your app, select Video interstitial or Banner interstitial (be sure to select the appropriate option for the type of interstitial ad you want to show).
• If you are showing a native ad in your app, select Native.

In the Device family drop-down, select the device family targeted by the app in which your ad unit will be used. The available options are: UWP (Windows 10), PC/Tablet (Windows 8.1), or Mobile (Windows Phone 8.x).

Configure the following additional settings as desired:

• If you select the UWP (Windows 10) device family for the ad unit, you can optionally configure mediation settings for the ad unit.
• If you select the PC/Tablet (Windows 8.1) or Mobile (Windows Phone 8.x) device family for a banner ad unit, you can optionally select Show community ads in your app to opt in to community ads.

If you haven’t yet set the COPPA compliance for the selected app, choose an option in the COPPA compliance section.

Click Create ad unit.

After you create the new ad unit, it appears in the table of available ad units in the Monetize > In-app ads page.

Review and edit ad units

After you create ad units for one or more apps in your account, these ad units appear in a table at the bottom of the Monetize > In-app ads page. This table displays the Application ID and Ad unit ID for each ad unit, along with other information. To show ads in your app, you’ll need to use these values in your code. For more information, see Set up ad units in your app.

If your app shows banner ads, assign these values to the ApplicationId and AdUnitId properties of your AdControl object.

If your app shows interstitial ads, pass these values to the RequestAd method of your InterstitialAd object.

If your app shows native ads, pass these values to the NativeAdsManagerV2 constructor.

You can use each ad unit in only one app. If you use an ad unit in more than one app, ads will not be served for that ad unit.

You can use multiple banner, interstitial, and native ad controls in a single app. In this scenario, we recommend that you assign a different ad unit to each control. Using different ad units for each control enables you to separately configure the mediation settings and get discrete reporting data for each control. This also enables our services to better optimize the ads we serve to your app.

To edit the mediation settings for a UWP ad unit or the COPPA compliance for the app in which the ad unit is used, click the ad unit name.

If an ad unit has no activity for the past six months, we will label it as Inactive, and eventually remove it from Partner Center. You can use filters to show only Active or Inactive ad units. If you see any ad units that you believe are inaccurately marked as Inactive, contact support.

Mediation settings

When you create a new UWP ad unit or edit an existing UWP ad unit, use the options in this section to configure ad mediation for the ad unit. Ad mediation enables you to maximize your ad revenue and app promotion capabilities by displaying ads from multiple ad networks, including ads from other paid ad networks and non-revenue generating ads for Microsoft app promotion campaigns. We take care of mediating banner ad requests from the ad networks you choose. If you have a UWP ad unit that is already associated with a banner, interstitial, or native ad in your app, enabling ad mediation requires no code changes in your app.

When you enable ad mediation for a UWP ad unit, you do not need to obtain an ad unit from third-party ad networks. Our ad mediation service automatically creates any necessary third-party ad units.

To configure ad mediation settings for a UWP ad unit in your app:

On the In-app ads page, go to the Mediation settings section and configuration your settings.

• By default, the Let Microsoft optimize my settings check box is selected. We recommend that you use this option. This option uses machine-learning algorithms to automatically choose the ad mediation settings for your app to help you maximize your ad revenue across the markets your app supports. When you use this option, you can also choose the ad networks you want to use in the configuration. Uncheck the ad networks that you don’t want to be part of the configuration and our algorithm will ensure that your app only receives ads from the selected ad networks.
• If you want to choose your own ad mediation settings, choose Modify default settings.

The remaining steps in this section are only applicable if you choose Modify default settings.

In the Target drop-down, choose Baseline to configure the default configuration for your ad mediation settings. This default configuration will be applied to all markets, except for markets where you define market-specific configurations.

Next, specify the ratio of ads you want to show in your control from paid networks (which pay you revenue for impressions) and other ad networks (which do not pay you revenue for impressions). To do this, enter a value between 0 and 100 in the Weight fields for Paid ad networks and Other ad networks.

In the Paid ad networks section, select the check box in the Active column for each paid network you want to use, and then use the arrows in the Rank column to order the networks by rank (this specifies how often each network should be used by your control).

If you have selected a Banner or Banner interstitial ad unit, you will also see a section named Other ad networks. The networks in this section do not earn you revenue for ad impressions. Instead, these networks show ads from sources such as app promotion campaigns.

In the Other ad networks section, select the check box in the Active column for each other network you want to use, and then use the arrows in the Rank column to order the networks by rank (this specifies how often each network should be used by your control). The following other networks are currently supported:

For each market where you want to override the default mediation configuration, select the market in the Target drop-down, and update the ad network selections and ranking.

Click Create ad unit (if you are creating a new ad unit) or Save (if you are editing an existing ad unit).

Supported paid ad networks

The following table lists the paid networks we currently support for each ad type. Note that some of these networks are not available in all markets.

Ad network	Description	Supported ad types
Oath and AppNexus	This is a Microsoft-managed ad network that serves ads through our partner networks, Oath and AppNexus. Note: Oath and AppNexus is always ranked first in the Paid ad networks list for banner ad units, and it cannot be changed to a lower ranking for these types of ads.	Banner, Video interstitial
AppNexus (direct)	Select this option to serve ads from AppNexus.	Video interstitial, Native
Microsoft App install ads	Select this option to serve app install ads or app re-engagement ads created by other developers in the Windows ecosystem who create promotional ad campaigns for their apps.	Banner, Banner interstitial, Native
MSN Content Recommendations	Select this option to serve ads from MSN Content Recommendations.	Banner, Banner interstitial
Outbrain	Select this option to serve ads from Outbrain.	Banner, Banner interstitial
Revcontent	Select this option to serve ads from Revcontent.	Banner, Native
Smaato	Select this option to serve ads from Smaato.	Banner
smartclip	Select this option to serve ads from smartclip.	Video interstitial
SpotX	Select this option to serve ads from SpotX.	Video interstitial
Taboola	Select this option to serve ads from Taboola.	Banner
Vungle	Select this option to serve ads from Vungle	Video interstitial
Undertone	Select this option to serve ads from Undertone.	Banner interstitial

Other ad networks

The following table lists the other networks we currently support for each ad type.

Ad network	Description	Supported ad types
Microsoft Community ads	If you create a promotional ad campaign for one of your apps and configure this campaign as a community ad campaign, select this options to show ads from this campaign.	Banner, Banner interstitial
Microsoft House ads	If you create a promotional ad campaign for one of your apps and configure this campaign as a house ad campaign, select this options to show ads from this campaign.	Banner, Banner interstitial

Supported markets for ad networks

The available ad networks serve ads in all supported markets, with the following exceptions.

Ad network	Supported markets
Revcontent	Brazil, Canada, France, Germany, Italy, Japan, Spain, United Kingdom, United States
Smaato	Brazil, Canada, France, Germany, Italy, Japan, Spain, United Kingdom, United States
smartclip	Austria, Belgium, Denmark, Finland, Germany, Italy, Netherlands, Norway, Sweden, Switzerland
Undertone	United States

COPPA compliance

When you create an ad unit or select an existing ad unit, the COPPA compliance section appears at the bottom of the page if the selected app for the ad unit has at least one submission that has reached the in the Store step in the app certification process.

For purposes of the Children’s Online Privacy Protection Act (“COPPA”), you must select This application is directed at children under the age of 13 in this section if your app is directed at children under the age of 13. If you select this option, Microsoft will take steps to disable its behavioral advertising services when delivering advertising into your app.

The COPPA compliance setting you choose is automatically applied to all ad units for the selected app.

If your app is directed at children under the age of 13, you have certain obligations under COPPA. For more information on your obligations, please see this page.

Publishing Applications using AD FS Preauthentication

Applies To: Windows Server 2016

This content is relevant for the on-premises version of Web Application Proxy. To enable secure access to on-premises applications over the cloud, see the Azure AD Application Proxy content.

This topic describes how to publish applications through Web Application Proxy using Active Directory Federation Services (AD FS) preauthentication.

For all types of application that you can publish using AD FS preauthentication, you must add a AD FS relying party trust to the Federation Service.

The general AD FS preauthentication flow is as follows:

This authentication flow is not applicable for clients that use Microsoft Store apps.

The client device attempts to access a published web application on a particular resource URL; for example https://app1.contoso.com/.

The resource URL is a public address on which Web Application Proxy listens for incoming HTTPS requests.

If HTTP to HTTPS redirection is enabled, Web Application Proxy will also listen for incoming HTTP requests.

Web Application Proxy redirects the HTTPS request to the AD FS server with URL encoded parameters, including the resource URL and the appRealm (a relying party identifier).

The user authenticates using the authentication method required by the AD FS server; for example, user name and password, two-factor authentication with a one-time password, and so on.

After the user is authenticated, the AD FS server issues a security token, the ‘edge token’, containing the following information and redirects the HTTPS request back to the Web Application Proxy server:

The resource identifier that the user attempted to access.

The user’s identity as a user principal name (UPN).

The expiry of the access grant approval; that is, the user is granted access for a limited period of time, after which they are required to authenticate again.

Signature of the information in the edge token.

Web Application Proxy receives the redirected HTTPS request from the AD FS server with the edge token and validates and uses the token as follows:

Validates that the edge token signature is from the federation service that is configured in the Web Application Proxy configuration.

Validates that the token was issued for the correct application.

Validates that the token has not expired.

Uses the user identity when required; for example to obtain a Kerberos ticket if the backend server is configured to use Integrated Windows authentication.

If the edge token is valid, Web Application Proxy forwards the HTTPS request to the published web application using either HTTP or HTTPS.

The client now has access to the published web application; however, the published application may be configured to require the user to perform additional authentication. If, for example, the published web application is a SharePoint site and does not require additional authentication, the user will see the SharePoint site in the browser.

Web Application Proxy saves a cookie on the client device. The cookie is used by Web Application Proxy to identify that this session has already been preauthenticated and that no further preauthentication is required.

When configuring the external URL and the backend server URL, make sure you include the fully qualified domain name (FQDN), and not an IP address.

This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. For more information, see Using Cmdlets.

Publish a Claims-based Application for Web Browser Clients

To publish an application that uses claims for authentication, you must add a relying party trust for the application to the Federation Service.

When publishing claims-based applications and accessing the application from a browser, the general authentication flow is as follows:

The client attempts to access a claims-based application using a web browser; for example, https://appserver.contoso.com/claimapp/.

The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server.

The AD FS server authenticates the user and the device and redirects the request back to Web Application Proxy. The request now contains the edge token. The AD FS server adds a single sign-on (SSO) cookie to the request because the user has already performed authentication against the AD FS server.

Web Application Proxy validates the token, adds its own cookie, and forwards the request to the backend server.

The backend server redirects the request to the AD FS server to get the application security token.

The request is redirected to the backend server by the AD FS server. The request now contains the application token and the SSO cookie. The user is granted access to the application and is not required to enter a user name or password.

This procedure describes how to publish a claims-based application, such as a SharePoint site, that will be accessed by web browser clients. Before you begin, make sure that you have done the following:

Created a relying party trust for the application in the AD FS Management console.

Verified that a certificate on the Web Application Proxy server is suitable for the application you want to publish.

To publish a claims-based application

On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

On the Publish New Application Wizard, on the Welcome page, click Next.

On the Preauthentication page, click Active Directory Federation Services (AD FS), and then click Next.

On the Supported Clients page, select Web and MSOFBA, and then click Next.

On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next.

On the Publishing Settings page, do the following, and then click Next:

In the Name box, enter a friendly name for the application.

This name is used only in the list of published applications in the Remote Access Management console.

In the External URL box, enter the external URL for this application; for example, https://sp.contoso.com/app1/.

In the External certificate list, select a certificate whose subject covers the external URL.

In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, https://sp/app1/.

Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://app-server/app1/. However, you cannot enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://apps.contoso.com/internal-app1/.

On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

On the Results page, make sure that the application published successfully, and then click Close.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

Publish an Integrated Windows authenticated-based Application for Web Browser Clients

Web Application Proxy can be used to publish applications that uses Integrated Windows authentication; that is, Web Application Proxy performs preauthentication as required, and can then perform SSO to the published application that uses Integrated Windows authentication. To publish an application that uses Integrated Windows authentication you must add a non-claims-aware relying party trust for the application to the Federation Service.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See Plan Active Directory.

To allow users to access applications that use Integrated Windows authentication, the Web Application Proxy server must be able to provide delegation for users to the published application. You can do this on the domain controller for any application. You can also do this on the backend server if it is running on Windows Server 2012 R2 or Windows Server 2012 . For more information, see What’s New in Kerberos Authentication.

For a walkthrough of how to configure Web Application Proxy to publish an application using Integrated Windows authentication, see Configure a site to use Integrated Windows authentication.

When using Integrated Windows authentication to backend servers, the authentication between Web Application Proxy and the published application is not claims-based, instead it uses Kerberos constrained delegation to authenticate end users to the application. The general flow is described below:

The client attempts to access a non-claims-based application using a web browser; for example, https://appserver.contoso.com/nonclaimapp/.

The web browser sends an HTTPS request to the Web Application Proxy server which redirects the request to the AD FS server.

The AD FS server authenticates the user and redirects the request back to Web Application Proxy. The request now contains the edge token.

Web Application Proxy validates the token.

If the token is valid, Web Application Proxy obtains a Kerberos ticket from the domain controller on behalf of the user.

Web Application Proxy adds the Kerberos ticket to the request as part of the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) token, and forwards the request to the backend server. The request contains the Kerberos ticket; therefore, the user is granted access to the application without the need for further authentication.

This procedure describes how to publish an application that uses Integrated Windows authentication, such as Outlook Web App, that will be accessed by web browser clients. Before you begin, make sure that you have done the following:

Created a non-claims-aware relying party trust for the application in the AD FS Management console.

Configured the backend server to support Kerberos constrained delegation on the domain controller or by using the Set-ADUser cmdlet with the -PrincipalsAllowedToDelegateToAccount parameter. Note that if the backend server is running on Windows Server 2012 R2 or Windows Server 2012 , you can also run this PowerShell command on the backend server.

Made sure that the Web Application Proxy servers are configured for delegation to the service principal names of the backend servers.

Verified that a certificate on the Web Application Proxy server is suitable for the application you want to publish.

To publish a non-claims-based application

On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

On the Publish New Application Wizard, on the Welcome page, click Next.

On the Preauthentication page, click Active Directory Federation Services (AD FS), and then click Next.

On the Supported Clients page, select Web and MSOFBA, and then click Next.

On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next.

On the Publishing Settings page, do the following, and then click Next:

In the Name box, enter a friendly name for the application.

This name is used only in the list of published applications in the Remote Access Management console.

In the External URL box, enter the external URL for this application; for example, https://owa.contoso.com/.

In the External certificate list, select a certificate whose subject covers the external URL.

In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, https://owa/.

Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://app-server/app1/. However, you cannot enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://apps.contoso.com/internal-app1/.

In the Backend server SPN box, enter the service principal name for the backend server; for example, HTTP/owa.contoso.com.

On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

On the Results page, make sure that the application published successfully, and then click Close.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

Publish an Application that uses MS-OFBA

Web Application Proxy supports access from Microsoft Office clients such as Microsoft Word that access documents and data on backend servers. The only difference between these applications and a standard browser is that the redirection to the STS is done not via regular HTTP redirection but with special MS-OFBA headers as specified in: https://msdn.microsoft.com/library/dd773463(v=office.12).aspx. Backend application may be claims or IWA. To publish an application for clients that use MS-OFBA, you must add a relying party trust for the application to the Federation Service. Depending on the application, you can use claims-based authentication or Integrated Windows authentication. Therefore, you must add the relevant relying party trust depending on the application.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See Plan Active Directory.

There are no additional planning steps if the application uses claims-based authentication. If the application used Integrated Windows authentication, see Publish an Integrated Windows authenticated-based Application for Web Browser Clients.

The authentication flow for clients that use the MS-OFBA protocol using claims-based authentication is described below. The authentication for this scenario can either use the application token in the URL, or in the body.

The user is working in an Office program, and from the Recent Documents list, opens a file on a SharePoint site.

The Office program shows a window with a browser control that requires the user to enter credentials.

In some cases, the window may not appear because the client is already authenticated.

Web Application Proxy redirects the request to the AD FS server, which performs the authentication.

The AD FS server redirects the request back to Web Application Proxy. The request now contains the edge token.

The AD FS server adds a single sign-on (SSO) cookie to the request because the user has already performed authentication against the AD FS server.

Web Application Proxy validates the token and forwards the request to the backend server.

The backend server redirects the request to the AD FS server to get the application security token.

The request is redirected to the backend server. The request now contains the application token and the SSO cookie. The user is granted access to the SharePoint site and is not required to enter a user name or password to view the file.

The steps to publish an application that uses MS-OFBA are identical to the steps for a claims-based application or a non-claims-based application. For claims-based applications, see Publish a Claims-based Application for Web Browser Clients, for non-claims-based applications, see Publish an Integrated Windows authenticated-based Application for Web Browser Clients. Web Application Proxy automatically detects the client and will authenticate the user as required.

Publish an Application that uses HTTP Basic

HTTP Basic is the authorization protocol used by many protocols, to connect rich clients, including smartphones, with your Exchange mailbox. For more information on HTTP Basic, see RFC 2617. Web Application Proxy traditionally interacts with AD FS using redirections; most rich clients don’t support cookies or state management. In this way Web Application Proxy enables the HTTP app to receive a non-claims relying party trust for the application to the Federation Service. See Plan Active Directory.

The authentication flow for clients that use HTTP Basic is described below and in this diagram:

The user attempts to access a published web application a telephone client.

The app sends an HTTPS request to the URL published by Web Application Proxy.

If the request does not contain credentials, Web Application Proxy returns an HTTP 401 response to the app containing the URL of the authenticating AD FS server.

The user sends the HTTPS request to the app again with authorization set to Basic and user name and Base 64 encrypted password of the user in the www-authenticate request header.

Because the device cannot be redirected to AD FS, the Web Application Proxy sends an authentication request to AD FS with the credentials that it has including username and password. The token is acquired on behalf of the device.

In order to minimize the number of requests sent to the AD FS, Web Application Proxy, validates subsequent client requests using cached tokens for as long as the token is valid. Web Application Proxy periodically cleans the cache. You can view the size of the cache using the performance counter.

If the token is valid, Web Application Proxy forwards the request to the backend server and the user is granted access to the published web application.

The following procedure explains how to publish HTTP basic applications.

To publish an HTTP Basic application

On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

On the Publish New Application Wizard, on the Welcome page, click Next.

On the Preauthentication page, click Active Directory Federation Services (AD FS), and then click Next.

On the Supported Clients page, select HTTP Basic and then click Next.

If you wish to enable access to the Exchange only from workplace joined devices, select the Enable access only for workplace joined devices box. For more information see Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.

On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next. Note that this list contains only on-claims relying parties.

On the Publishing Settings page, do the following, and then click Next:

In the Name box, enter a friendly name for the application.

This name is used only in the list of published applications in the Remote Access Management console.

In the External URL box, enter the external URL for this application; for example, mail.contoso.com

In the External certificate list, select a certificate whose subject covers the external URL.

In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, mail.contoso.com.

On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

On the Results page, make sure that the application published successfully, and then click Close.

Windows PowerShell equivalent commands

The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

This Windows PowerShell script enables preauthentication for all devices, not just workplace joined devices.

The following preauthenticates only workplace joined devices:

Publish an Application that uses OAuth2 such as a Microsoft Store App

To publish an application for Microsoft Store apps, you must add a relying party trust for the application to the Federation Service.

To allow Web Application Proxy to perform single sign-on (SSO) and to perform credentials delegation using Kerberos constrained delegation, the Web Application Proxy server must be joined to a domain. See Plan Active Directory.

Web Application Proxy supports publishing only for Microsoft Store apps that use the OAuth 2.0 protocol.

In the AD FS Management console, you must make sure that the OAuth endpoint is proxy enabled. To check if the OAuth endpoint is proxy enabled, open the AD FS Management console, expand Service, click Endpoints, in the Endpoints list, locate the OAuth endpoint and make sure that the value in the Proxy Enabled column is Yes.

The authentication flow for clients that use Microsoft Store apps is described below:

The Web Application Proxy redirects to the AD FS server for authentication. Because Microsoft Store apps do not support redirects, if you use Microsoft Store apps, it is necessary to set the URL of the AD FS server using the Set-WebApplicationProxyConfiguration cmdlet and the OAuthAuthenticationURL parameter.

Microsoft Store apps can be published only using Windows PowerShell.

The client attempts to access a published web application using a Microsoft Store app.

The app sends an HTTPS request to the URL published by Web Application Proxy.

Web Application Proxy returns an HTTP 401 response to the app containing the URL of the authenticating AD FS server. This process is known as ‘discovery’.

If the app knows the URL of the authenticating AD FS server and already has a combo token containing the OAuth token and the edge token, steps 2 and 3 are skipped in this authentication flow.

The app sends an HTTPS request to the AD FS server.

The app uses the web authentication broker to generate a dialog box in which the user enters credentials to authenticate to the AD FS server. For information about web authentication broker, see Web authentication broker.

After successful authentication, the AD FS server creates a combo token that contains the OAuth token and the edge token and sends the token to the app.

The app sends an HTTPS request containing the combo token to the URL published by Web Application Proxy.

Web Application Proxy splits the combo token into its two parts and validates the edge token.

If the edge token is valid, Web Application Proxy forwards the request to the backend server with only the OAuth token. The user is granted access to the published web application.

This procedure describes how to publish an application for OAuth2. This type of application can be published only using Windows PowerShell. Before you begin, make sure that you have done the following:

Created a relying party trust for the application in the AD FS Management console.

Made sure that the OAuth endpoint is proxy enabled in the AD FS Management console and make a note of the URL Path.

Verified that a certificate on the Web Application Proxy server is suitable for the application you want to publish.

To publish an OAuth2 app

On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

On the Publish New Application Wizard, on the Welcome page, click Next.

On the Preauthentication page, click Active Directory Federation Services (AD FS), and then click Next.

On the Supported Clients page, select OAuth2 and then click Next.

On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next.

On the Publishing Settings page, do the following, and then click Next:

In the Name box, enter a friendly name for the application.

This name is used only in the list of published applications in the Remote Access Management console.

In the External URL box, enter the external URL for this application; for example, https://server1.contoso.com/app1/.

In the External certificate list, select a certificate whose subject covers the external URL.

In order to make sure your users can access your app, even if they neglect to type HTTPS in the URL, select the Enable HTTP to HTTPS Redirection box.

In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, https://sp/app1/.

Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://app-server/app1/. However, you cannot enter an external URL of https://apps.contoso.com/app1/ and a backend server URL of https://apps.contoso.com/internal-app1/.

On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

On the Results page, make sure that the application published successfully, and then click Close.

Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.