Today, security is at the centre of everything, and designing a reliable and robust application requires strong authentication and authorization across every layer. In this three-part series, we’ll explore how to secure three-tier architectures with Microsoft Entra ID. We’ll cover key concepts and authentication flows, with each blog post focusing on an architectural scenario of increasing complexity. We’ll examine how each layer benefits from secure, token-based authentication and access management.

In this first blog post, we introduce Microsoft Entra ID’s role in securing a basic three-tier architecture, guiding you through implementing Microsoft Entra ID across the UI, API, and data layers. Parts 2 and 3 will explore more complex architectures, including setups with microservices and orchestrator services. For the purposes of this blog post, we assume that all components are running on the Azure cloud.

Key terminology and concepts

Technical Components

• Microsoft Entra ID: A cloud-based identity and access management service that your employees can use to access resources.
• Microsoft Authentication Library (MSAL): Enables developers to acquire security tokens from the Microsoft identity platform (Microsoft Entra ID) to authenticate users and access secured APIs.
• Managed identity: Allows services running on Azure to authenticate securely without needing to manage credentials explicitly.

Key concepts

• An ID token is a type of security token that serves as proof of authentication, confirming that a user is successfully authenticated. 
• An access token is a type of security token designed for authorization, granting access to specific resources on behalf of an authenticated user or workload.
• Token validation ensures tokens are generated by Microsoft Entra ID and that their contents haven’t been changed.
• The hybrid flow extends the authorization code flow to additionally request an ID token as well as an access token.
• The on-behalf-of (OBO) flow allows a web API to use an identity other than its own, typically that of the user calling the web API, to call another web API.
• Delegated permission allows a client application to access resources on behalf of a user.
• Application permission provides access to resources without requiring a user.

Understanding three-tier architecture

Three-tier architecture is a well-established design that organizes applications into three logical and physical computing tiers:

• The UI layer (Client app): The user interface where users interact with the application.
• The API layer: The business logic layer where data is processed.
• The data layer: The data storage layer where application data is securely stored and managed.

Microsoft Entra ID enables you to establish secure access and manage identities across these layers, reducing security risks and improving scalability. Let’s see how each layer is secured in our basic three-tier architecture.

Scenario #1: A client app, API service, and a database

UI layer (Client app)

The client app serves as the primary entry point for users.

Regardless of the platform type—web, mobile, or desktop—the app can use MSAL to authenticate users. MSAL enables the app to acquire tokens that both identify the requestor and verify their credentials.

To be able to authenticate a user, an app needs an associated app registration in Microsoft Entra ID. Registering your application establishes a trust relationship between your app and the Microsoft identity platform and helps to identify which client is requesting access to user data on behalf of the user.

As part of the sign-in process, the user is redirected to the Microsoft Entra ID sign-in page. Once the user completes the authentication process (including MFA if configured), the client app allows the user to log in to the app (Transaction 1). The advantage of this approach is that the application does not need to manage credentials or multi-factor authentication as Microsoft Entra ID handles the user interface, simplifying the process for developers.

The next step for the client application is to invoke the main service API by attaching the access token in the authorization bearer header (Transaction 2) to retrieve or update data for its functionality. The main service API also relies on Microsoft Entra ID to protect its API and data.

To secure ’Transaction 2’, there will be another app registration for the main service API which exposes the APIs. The client app requests an access token for that API from Microsoft Entra ID on behalf of the user. This process can also be combined with the sign-in request through the hybrid flow, where the initial sign-in request asks for both the ID token (for the client app to identify the user) and the access token (which can be used as authorization bearer while invoking the main service API), thus completing the process in a single transaction with Microsoft Entra ID.

API layer (Main service)

The main service API processes requests from the client app (Transaction 2) and validates the authorization by decoding access tokens received through the authorization bearer header.

As mentioned above, the main service API will have its own app registration in Microsoft Entra ID. It must download the public key from Microsoft Entra ID, which corresponds to the private key used to sign the token, (Transaction 3), and validate the signature, audience, issuer, and app-specific roles/claims to allow only authorized users and app requests. If validation fails, ‘Transaction 2’ will be denied with a 401 (Unauthorized) status.

Detailed guidelines on validating access tokens can be found here.

After successful validation of the user and app, the main service API is ready to perform operations on the database. There are two approaches:

• Variation 1: OBO Flow

  • The main service API should request an access token for the data layer in exchange for the access token it received through ‘Transaction 1’. This process is known as the On-Behalf-Of (OBO) flow (Transaction 4).

  • For practical implementation, let’s assume the data layer is Azure SQL. The main service API requests a token for the Azure SQL delegated permission through the OBO flow and then attaches it to the authorization bearer header while invoking Azure SQL methods (Transaction 5).

  • The advantage of this approach is that the user context persists throughout the entire transaction from the client app to the data layer. That means both the client and the user must be authorized to make the request.

• Variation 2: Managed Identity Flow

  • Managed identity is set up between the main service API and the data layer.
  • For example, if the API is an Azure function and the data layer is Azure SQL, the managed identity is enabled for the function app, and Azure SQL RBAC is configured to establish trust with the system-assigned identity (Transaction 7).
  • In this approach, the user context is lost in the transaction, and the data layer solely trusts that the main service API is allowing only authorized users to invoke the operation as intended.
  • In this approach, it is important to ensure that the database layer is accessed exclusively through the main service API and not from any other services. Failure to do so may lead to improper handling of authorization.

Data layer

The data layer is secured through Microsoft Entra ID in two variations as outlined above, and the authorization of requests is handled accordingly. In both scenarios there is a pre-established trust setup between the resource and Microsoft Entra ID.

• In the case of ‘Variation 1’, the database layer downloads the public key from Microsoft Entra ID, which corresponds to the private key used to sign the token, caches them for 24 hours (Transaction 6), and validates the signature, audience, issuer, and app-specific roles/claims to allow only authorized users and app requests.
• In the case of ‘Variation 2’, the database layer relies on the Azure managed identity implementation and validates the RBAC configured between the database layer and the main service API, without validating the user (Transaction 7).

Let’s recap

In this post, we demonstrated how Microsoft Entra ID can strengthen security across a three-tier architecture by implementing secure token-based authentication and access management at each layer:

• UI Layer: We registered the client app in Microsoft Entra ID, enabling MSAL to handle user authentication. By offloading MFA and sign-in flows to Microsoft Entra ID, we simplified the authentication process while maintaining robust security.
• API Layer: We explored how the main service API processes requests from the client app and validates authorization by decoding access tokens. We also looked at two approaches to how the main service API can perform operations on the database.
• Data Layer: Finally, we further explored the two approaches for secure database access—the OBO flow, which preserves user context, and managed identity, in which RBAC can be configured to establish trust with the system-assigned identity.

Stay connected and informed

To learn more or test out other features in the Microsoft Entra portfolio, visit our developer center. Make sure you subscribe to the Identity developer blog for more insights and to keep up with the latest on all things Identity. And follow us on YouTube for video overviews, tutorials, and deep dives.

In the next post, we’ll build on this foundation and explore how Microsoft Entra ID secures more complex architectures involving orchestrator services and microservices. Stay tuned!

This blog post has been reviewed by Den Delimarsky, Kyle Marsh, and Merill Fernando, Principal Product Managers at Microsoft. Their valuable feedback has been considered and incorporated into the content to enhance its quality and accuracy.