| title | description | author | ms.author | ms.topic | ms.date | ms.custom |
|---|---|---|---|---|---|---|
Securely connect to Azure resources |
Shows you how to connect to other Azure services such as a database, storage, or another app. This overview recommends the more secure method for connecting. |
cephalin |
cephalin |
article |
07/06/2024 |
AppServiceConnectivity |
Your app service might need to connect to other Azure services such as a database, storage, or another app. This overview recommends different methods for connecting and when to use them.
Today, the decision for a connectivity approach is closely related to secrets management. The common pattern of using connection secrets in connection strings, such as username and password, secret key, etc. is no longer considered the most secure approach for connectivity. The risk is even higher today because threat actors regularly crawl public GitHub repositories for accidentally committed connection secrets. For cloud applications, the best secrets management is to have no secrets at all. When you migrate to Azure App Service, your app might start with secrets-based connectivity, and App Service lets you keep secrets securely. However, Azure can help secure your app's back-end connectivity through Microsoft Entra authentication, which eliminates secrets altogether in your app.
| Connection method | When to use |
|---|---|
| Connect with an app identity | * You want to remove credentials, keys, or secrets completely from your application. * The downstream Azure service supports Microsoft Entra authentication, such as Microsoft Graph. * The downstream resource doesn't need to know the current signed-in user or doesn't need granular authorization of the current signed-in user. |
| Connect on behalf of the signed-in user | * The app must access a downstream resource on behalf of the signed-in user. * The downstream Azure service supports Microsoft Entra authentication, such as Microsoft Graph. * The downstream resource must perform granular authorization of the current signed-in user. |
| Connect using secrets | * The downstream resource requires connection secrets. * Your app connects to non-Azure services, such as an on-premises database server. * The downstream Azure service doesn't support Microsoft Entra authentication yet. |
If your app already uses a single set of credentials to access a downstream Azure service, you can quickly convert the connection to use an app identity instead. A managed identity from Microsoft Entra ID lets App Service access resources without secrets, and you can manage its access through role-based access control (RBAC). A managed identity can connect to any Azure resource that supports Microsoft Entra authentication, and the authentication takes place with short-lived tokens.
The following image demonstrates the following an App Service connecting to other Azure services:
- A: User visits Azure app service website.
- B: Securely connect from App Service to another Azure service using a managed identity.
- C: Securely connect from App Service to Microsoft Graph using a managed identity.
:::image type="content" source="media/scenario-secure-app-overview/web-app.svg" alt-text="Diagram showing managed identity accessing a resource with or without the user's identity.":::
Examples of using application secrets to connect to a database:
- Tutorial: Connect to Azure databases from App Service without secrets using a managed identity
- Tutorial: Connect to SQL Database from .NET App Service without secrets using a managed identity
- Tutorial: Connect to a PostgreSQL Database from Java Tomcat App Service without secrets using a managed identity
Your app might need to connect to a downstream service on behalf of the signed-in user. App Service lets you easily authenticate users using the most common identity providers (see Authentication and authorization in Azure App Service and Azure Functions). If you use the Microsoft provider (Microsoft Entra authentication), you can then flow the signed-in user to any downstream service. For example:
- Run a database query that returns confidential data that the signed-in user is authorized to read.
- Retrieve personal data or take actions as the signed-in user in Microsoft Graph.
The following image demonstrates an application securely accessing an SQL database on behalf of the signed-in user.
:::image type="content" source="./media/tutorial-connect-app-access-sql-database-as-user-dotnet/architecture.png" alt-text="Architecture diagram for tutorial scenario.":::
Some common scenarios are:
- Connect to Microsoft Graph on behalf of the user
- Connect to an SQL database on behalf the user
- Connect to another App Service app on behalf of the user
- Flow the signed-in user through multiple layers of downstream services
There are two recommended ways to use secrets in your app: using secrets stored in Azure Key Vault or secrets in App Service app settings.
Azure Key Vault can be used to securely store secrets and keys, monitor access and use of secrets, and simplify administration of application secrets. If the downstream service doesn't support Microsoft Entra authentication or requires a connection string or key, use Key Vault to store your secrets and connect your app to Key Vault with a managed identity and retrieve the secrets. Your app can access they key vault secrets as Key Vault references in the app settings.
Benefits of managed identities integrated with Key Vault include:
- Access to the key vault secret is restricted to the app.
- App contributors, such as administrators, might have complete control of the App Service resources, and at the same time have no access to the key vault secrets.
- No code change is required if your application code already accesses connection secrets with app settings.
- Key Vault provides monitoring and auditing of who accessed secrets.
- Rotation of key vault secrets requires no changes in App Service.
The following image demonstrates App Service connecting to Key Vault using a managed identity and then accessing an Azure service using secrets stored in Key Vault:
:::image type="content" source="media/tutorial-connect-overview/app-service-connect-key-vault-managed-identity.png" alt-text="Diagram showing app service using a secret stored in Key Vault and managed with Managed identity to connect to Azure AI services.":::
For apps that connect to services using secrets (such as usernames, passwords, and API keys), App Service can store them securely in app settings. These secrets are injected into your application code as environment variables at app startup. App settings are always encrypted when stored (encrypted-at-rest). For more advanced secrets management, such as secrets rotation, access policies, and audit history, try using Key Vault.
Examples of using application secrets to connect to a database:
- Tutorial: Deploy an ASP.NET Core and Azure SQL Database app to Azure App Service
- Tutorial: Deploy an ASP.NET app to Azure with Azure SQL Database
- Tutorial: Deploy a PHP, MySQL, and Redis app to Azure App Service
- Deploy a Node.js + MongoDB web app to Azure
- Deploy a Python (Django or Flask) web app with PostgreSQL in Azure
- Tutorial: Build a Tomcat web app with Azure App Service on Linux and MySQL
- Tutorial: Build a Java Spring Boot web app with Azure App Service on Linux and Azure Cosmos DB
Learn how to:
- Securely store secrets in Azure Key Vault.
- Access resources using a managed identity.
- Store secrets using App Service app settings.
- Connect to Microsoft Graph as the user.
- Connect to an SQL database as the user.
- Connect to another App Service app as the user.
- Connect to another App Service app and then a downstream service as the user.