Document Details

1. Use the accessToken in the `Authentication` header as the `bearerToken` value. 

    

## Create and deploy apps

Create the resource group, web app plan, and the web app, then deploy in a single step.

::: zone pivot="platform-windows"  

1. Change into the `frontend` web app directory.

   

1. Create and deploy the front-end web app with the [az webapp up](/cli/azure/webapp#az-webapp-up) command. The web app name has to be globally unique. Replace `<front-end-app-name>` with a unique string of letters and numbers. 

   

The commands add a `loginParameters` property with other custom scopes. Here's an explanation of the requested scopes:

- `openid` is requested by App Service by default already. For more information, see [OpenID Connect Scopes](../active-directory/develop/v2-permissions-and-consent.md#openid-connect-scopes).
- [offline_access](../active-directory/develop/v2-permissions-and-consent.md#offline_access) is included here for convenience, in case you want to [refresh tokens](#what-happens-when-the-front-end-token-expires).
- `api://<back-end-client-id>/user_impersonation` is an exposed API in your back-end app registration. It's the scope that gives you a JWT that includes the back-end app as a [token audience](https://wikipedia.org/wiki/JSON_Web_Token). 

> [!TIP]
> - To view the `api://<back-end-client-id>/user_impersonation` scope in the Azure portal, go to the **Authentication** page for the back-end app, select the link under **Identity provider**, then select **Expose an API** in the left menu.
> - To configure the required scopes using a web interface instead, see [Refresh auth tokens](configure-authentication-oauth-tokens.md#refresh-auth-tokens).
> - Some scopes require admin or user consent. This requirement causes the consent request page appear when a user signs into the front-end app in the browser. To avoid this consent page, add the front end's app registration as an authorized client application in the **Expose an API** page. Select **Add a client application** and supply the client ID of the front end's app registration.

Your apps are now configured. The front end is now ready to access the back end with a proper access token.

For information on how to configure the access token for other providers, see [Refresh identity provider tokens](configure-authentication-oauth-tokens.md#refresh-auth-tokens).

## Configure backend App Service to accept a token only from the front-end App Service

You should also configure the back-end App Service to only accept a token from the front-end App Service. Not doing this configuration results in a *403: Forbidden error* when you pass the token from the front end to the back end.

You can implement this approach by using the same Azure CLI process you used in the previous step.

1. Get the `appId` of the front-end App Service. You can get this value on the **Authentication** page of the front-end App Service.

1. Run the following Azure CLI, substituting the `<back-end-app-name>` and `<front-end-app-id>`.

    This tutorial returns a *fake* profile to simplify the scenario. The [next tutorial](tutorial-connect-app-access-microsoft-graph-as-user-javascript.md) in this series demonstrates how to exchange the back-end `bearerToken` for a new token with the scope of a downstream Azure service, such as Microsoft Graph.

## <a name="call-api-securely-from-server-code"></a>Back end returns profile to front end

If the request from the front end isn't authorized, the back-end App Service rejects the request with a 401 HTTP error code *before* the request reaches your application code. When the back-end code is reached, because it includes an authorized token, extract the `bearerToken` to get the `accessToken`. 

View the back-end app's source code: