Almost every aspect of the internet world requires authentication. Authentication is the process of verifying client or server identity before accessing resources to protect information security. Azure App Service provides sets of authentication technologies to protect and secure your web application. However, it is a steep learning curve to know all of them, and we often get lost in the details of documentations. The purpose of this article is to give you an intuitive way to understand the authentication features in App Service and a high-level summary of different authentication models and their usage scenarios.
Speaking about authentication in App Service, we can make an analogy with network traffic that there is incoming calls and outgoing calls. Similarly, authentications also have direction, and we can categorize them into incoming authentication and outgoing authentication.
Incoming authentication is when a user or app needs to authenticate itself when accessing the web app. The web app is the target server, and the user or the other app is the source that issue authentication request. In App Service, we provide following incoming authentication options.
Built-in App Service Authentication (Easy Auth)
Azure App Service provides built-in authentication and authorization capabilities, enabling us to sign in users and access data by writing minimal or no code. The built-in authentication feature can work with various identity providers that supports OpenID Connect protocol.
The client can authenticate as a user or as a service. The difference between them is that user authentication requires user sign-in, the user will be prompted to enter their credential.
Authenticate as a service does not have user sign-in step. Instead, it acquires access token from the identity provider and uses the token for authentication with the destination app. Managed identity is a feature in Azure AD that supports this scenario. The built-in authentication can accept incoming authentication from other Azure resources with managed identity like Azure Spring Apps and Logic App.
The built-in authentication allows some degree of customizations and is largely controlled by the platform. If you want more customization, you need to write your own authentication module in your app code.
Code Implementation of Authentication
This is writing our own code to implement authentication module in the app. It guarantees the highest degree of customization. We can use any authentication protocols, identity providers and authentication SDK of our choice.
Writing our own code requires deep understanding of the authentication architecture. This is usually more complicated given the nature of a secure architecture. Also, more time and efforts will be spent to develop and test the functionality. One mistake many people make is to have built-in authentication on App Service enabled while also implementing their own authentication module in the code with the same identity provider. It is unnecessary to have users sign into the same identity provider twice. Such implementation is also error prone as processing the authentication data could be conflicting with repeated modules.
App Service can accept client certificate from client request. The feature is enabled through app configuration: Configuration >> General Settings >> Client certificate mode. App Service only does the forwarding of the certificate to the app code through "X-ARR-ClientCert" request header. The app code is responsible for validating the client certificate.
Outgoing authentication means the app now acts as a client that it needs to authenticate itself before accessing another apps or resources. The web app now becomes the source of sending authentication request. The direction goes opposite with the incoming authentication. In App Service, we can leverage on following features to make outgoing authentication.
Managed identities provide an automatically managed identity in AAD for your app service when connecting to resources that support AAD authentication. The client credentials are stored on the app service and is not visible to the users or developers. Only the app itself can access the credential and request access token from AAD. This is the most secure means of outgoing authentication in app service. However, not all Azure resources support AAD authentication and not all of the feature in App Service support managed identity when it needs to make outbound call to other Azure resources. The authentication flow is illustrated as below.
Use Key Vault
We can also use key vault to store client secret and client certificate to call other resources that do not support managed identities. By this way, we use managed identities to get credential from key vault and use that credential to access other resources. As the credentials are accessed by the managed identity of the App Service, they are not exposed to users who can't read the Key Vault. This method is also highly secure and is applicable to many more scenarios.
Credential and connection strings can be saved in App Service app settings. The app settings can then be accessed via environmental variables in the code to connect to other resources. The method is less complicated to implement and use. However, the solution is not secure as the credential is stored as text in the app setting and can be exposed to the app contributors or its developers. Therefore, we don't recommend this method in production environment. But it is convenient to implement during development phase.
Call API on behalf of Users
The above scenarios are about authenticating with app's identity. Apps can also use the identity of the signed-in users to access other protected resources. The App Service built-in authentication feature supports this scenario. For example, when the app is integrated with user authentication through Microsoft Identity Platform, the app can access other web APIs that are also registered in AAD on behalf of the signed-in user if the permissions are set. This is also a secured way of outgoing authentication if you would like the target resource to be accessed with user's identity.
When starting to design the authentication architecture of applications, we need to have a clear picture about the authentication flow as who is the target server to accept authentication request and who is the client that want to access the resource securely. Furthermore, we should think about whether the authentication flow involves a user sign-in or just app identity. Then, we choose the right authentication method considering the technology stack and level of security, whether the credentials can be exposed to anyone. With all the considerations, Azure App Service has provided various authentication options that tailors your needs. You can build your app securely with these easy-to-use features that suit you best.