In this article

Tutorial: Authenticate and authorize users end-to-end in Azure App Service

08/07/2018

14 minutes to read

Contributors

In this article

Azure App Service provides a highly scalable, self-patching web hosting service. In addition, App Service has built-in support for user authentication and authorization. This tutorial shows how to secure your apps with App Service authentication and authorization. It uses an ASP.NET Core app with an Angular.js front end, but it is only for an example. App Service authentication and authorization support all language runtimes, and you can learn how to apply it to your preferred language by following the tutorial.

Open Azure Cloud Shell

Azure Cloud Shell is a free, interactive shell that you can use to run the steps in this article. Common Azure tools are preinstalled and configured in Cloud Shell for you to use with your account. Select Copy to copy the code, paste it in Cloud Shell, and then press Enter to run it. There are a few ways to open Cloud Shell:

Select Try It in the upper-right corner of a code block.

Open Cloud Shell in your browser.

Select the Cloud Shell button on the menu in the upper-right corner of the Azure portal.

Deploy apps to Azure

In this step, you deploy the project to two App Service apps. One is the front-end app and the other is the back-end app.

Configure a deployment user

In the Azure Cloud Shell, configure deployment credentials with the az webapp deployment user set command. This deployment user is required for FTP and local Git deployment to a web app. The username and password are account level. They're different from your Azure subscription credentials.

In the following example, replace <username> and <password>, including the brackets, with a new username and password. The username must be unique within Azure. The password must be at least eight characters long, with two of the following three elements: letters, numbers, and symbols.

You get a JSON output with the password shown as null. If you get a 'Conflict'. Details: 409 error, change the username. If you get a 'Bad Request'. Details: 400 error, use a stronger password.

You configure this deployment user only once. You can use it for all your Azure deployments.

Note

Record the username and password. You need them to deploy the web app later.

Create Azure resources

In the Cloud Shell, run the following commands to create two web apps. Replace <front_end_app_name> and <back_end_app_name> with two globally unique app names (valid characters are a-z, 0-9, and -). For more information on each command, see RESTful API with CORS in Azure App Service.

Save the URLs of the Git remotes for your front-end app and back-end app, which are shown in the output from az webapp create.

Push to Azure from Git

Back in the local terminal window, run the following Git commands to deploy to the back-end app. Replace <deploymentLocalGitUrl-of-back-end-app> with the URL of the Git remote that you saved from Create Azure resources. When prompted for credentials by Git Credential Manager, make sure that you enter your deployment credentials, not the credentials you use to log in to the Azure portal.

In the local terminal window, run the following Git commands to deploy the same code to the front-end app. Replace <deploymentLocalGitUrl-of-front-end-app> with the URL of the Git remote that you saved from Create Azure resources.

The first line makes a DELETE /api/Todo/{id} call to the back-end API app.

Save your all your changes. In the local terminal window, deploy your changes to the front-end app with the following Git commands:

git add .
git commit -m "call back-end API"
git push frontend master

Check your changes

Navigate to http://<front_end_app_name>.azurewebsites.net and add a few items, such as from front end 1 and from front end 2.

Navigate to http://<back_end_app_name>.azurewebsites.net to see the items added from the front-end app. Also, add a few items, such as from back end 1 and from back end 2, then refresh the front-end app to see if it reflects the changes.

Configure auth

In this step, you enable authentication and authorization for the two apps. You also configure the front-end app to generate an access token that you can use to make authenticated calls to the back-end app.

From the management page of the AD application, copy the Application ID to a notepad. You need this value later.

Enable authentication and authorization for front-end app

Follow the same steps for the front-end app, but skip the last step. You don't need the Application ID for the front-end app. Keep the Azure Active Directory Settings page open.

If you like, navigate to http://<front_end_app_name>.azurewebsites.net. It should now direct you to a secured sign-in page. After you sign in, you still can't access the data from the back-end app, because you still need to do three things:

Grant the front end access to the back end

Configure App Service to return a usable token

Use the token in your code

Tip

If you run into errors and reconfigure your app's authentication/authorization settings, the tokens in the token store may not be regenerated from the new settings. To make sure your tokens are regenerated, you need to sign out and sign back in to your app. An easy way to do it is to use your browser in private mode, and close and reopen the browser in private mode after changing the settings in your apps.

Grant front-end app access to back end

Now that you've enabled authentication and authorization to both of your apps, each of them is backed by an AD application. In this step, you give the front-end app permissions to access the back end on the user's behalf. (Technically, you give the front end's AD application the permissions to access the back end's AD application on the user's behalf.)

At this point, you should be in the Azure Active Directory Settings page for the front-end app. If not, go back to that page.

Click Manage Permissions > Add > Select an API.

In the Select an API page, type the AD application name of your back-end app, which is the same as your back-end app name by default. Select it in the list and click Select.

Configure App Service to return a usable access token

The front-end app now has the required permissions. In this step, you configure App Service authentication and authorization to give you a usable access token for accessing the back end. For this step, you need the back end's Application ID, which you copied from Enable authentication and authorization for back-end app.

Sign in to Azure Resource Explorer. At the top of the page, click Read/Write to enable editing of your Azure resources.

Call API securely from server code

In this step, you enable your previously modified server code to make authenticated calls to the back-end API.

Your front-end app now has the required permission and also adds the back end's Application ID to the login parameters. Therefore, it can obtain an access token for authentication with the back-end app. App Service supplies this token to your server code by injecting a X-MS-TOKEN-AAD-ACCESS-TOKEN header to each authenticated request (see Retrieve tokens in app code).

Note

These headers are injected for all supported languages. You access them using the standard pattern for each respective language.

In the local repository, open Controllers/TodoController.cs again. Under the TodoController(TodoContext context) constructor, add the following code:

You should now be able to create, read, update, and delete data from the back-end app as before. The only difference now is that both apps are now secured by App Service authentication and authorization, including the service-to-service calls.

Congratulations! Your server code is now accessing the back-end data on behalf of the authenticated user.

Call API securely from browser code

In this step, you point the front-end Angular.js app to the back-end API. This way, you learn how to retrieve the access token and make API calls to the back-end app with it.

While the server code has access to request headers, client code can access GET /.auth/me to get the same access tokens (see Retrieve tokens in app code).

This step is not related to authentication and authorization. However, you need it so that your browser allows the cross-domain API calls from your Angular.js app. For more information, see Add CORS functionality.

Point Angular.js app to back-end API

In the local repository, open wwwroot/index.html.

In Line 51, set the apiEndpoint variable to the URL of your back-end app (https://<back_end_app_name>.azurewebsites.net). Replace <back_end_app_name> with your app name in App Service.

In the local repository, open wwwroot/app/scripts/todoListSvc.js and see that apiEndpoint is prepended to all the API calls. Your Angular.js app is now calling the back-end APIs.

Add access token to API calls

In wwwroot/app/scripts/todoListSvc.js, above the list of API calls (above the line getItems : function(){), add the following function to the list:

The new change adds the revolve mapping that calls /.auth/me and sets the access token. It makes sure you have the access token before instantiating the todoListCtrl controller. That way all API calls by the controller includes the token.

Deploy updates and test

Save your all your changes. In the local terminal window, deploy your changes to the front-end app with the following Git commands:

Navigate to https://<front_end_app_name>.azurewebsites.net again. You should now be able to create, read, update, and delete data from the back-end app, directly in the Angular.js app.

Congratulations! Your client code is now accessing the back-end data on behalf of the authenticated user.

When access tokens expire

Your access token expires after some time. For information on how to refresh your access tokens without requiring users to reauthenticate with your app, see Refresh identity provider tokens.

Clean up resources

In the preceding steps, you created Azure resources in a resource group. If you don't expect to need these resources in the future, delete the resource group by running the following command in the Cloud Shell:

az group delete --name myAuthResourceGroup

This command may take a minute to run.

Next steps

What you learned:

Enable built-in authentication and authorization

Secure apps against unauthenticated requests

Use Azure Active Directory as the identity provider

Access a remote app on behalf of the signed-in user

Secure service-to-service calls with token authentication

Use access tokens from server code

Use access tokens from client (browser) code

Advance to the next tutorial to learn how to map a custom DNS name to your web app.