Azure Entra ID Implementation Guide

Shohanur RahmanShohanur Rahman
5 min read

Introduction to Authentication and Authorization

Before we dive into the Azure Entra ID implementation, let’s break down two key concepts: Authentication and Authorization.

Authentication

Authentication is the process of verifying who the user is. It answers the question, “Is this user really who they claim to be?”

In the context of Azure Entra ID, authentication is handled by verifying user credentials, such as username and password, or through more secure methods like multi-factor authentication (MFA) or OAuth2/OpenID Connect (OIDC) tokens. Azure Entra ID acts as the Identity Provider (IdP) in this process.

Authorization

Authorization, on the other hand, determines what an authenticated user is allowed to do. It answers the question, “What actions can this user perform?”

In Azure Entra ID, once a user is authenticated, Access Tokens are issued, and they contain scopes and roles that dictate what actions the user can perform within your application.


Evolution of Authentication Mechanisms

Authentication mechanisms have evolved significantly over time to become more secure and user-friendly. Here are some of the notable developments:

  • Password-Based Authentication: Traditional method where users provide credentials (username/password). It’s prone to security issues (e.g., password leaks, brute-force attacks).

  • Token-Based Authentication: Introduction of OAuth 2.0 and OpenID Connect (OIDC). This shifts the focus from passwords to tokens, which are more secure and prevent credentials from being shared directly.

  • Multi-Factor Authentication (MFA): Introduces an additional layer of security by requiring users to authenticate via another factor (e.g., SMS code, Authenticator App).

  • Modern OAuth 2.0 Flows: Now include mechanisms such as PKCE (Proof Key for Code Exchange), designed to provide better security for public clients like SPAs (Single Page Applications).


Authorization with PKCE Mechanism Flow

What is PKCE?

PKCE (Proof Key for Code Exchange) is an extension to the OAuth 2.0 Authorization Code flow, used to prevent certain types of attacks (like the authorization code interception attack).

PKCE Flow in Detail

The PKCE flow is especially useful in SPAs (Single Page Applications) or mobile apps, where you cannot securely store secrets. It provides a way for the app to prove that it is the legitimate recipient of the authorization code.

Steps in PKCE Flow:

  1. Client Creates a Code Verifier and Code Challenge:

    • The client (frontend app) creates a code_verifier, which is a random string.

    • The app hashes this code_verifier using SHA256 and generates a code_challenge.

  2. User Authentication:

    • The app redirects the user to the Azure Entra ID authorization endpoint, sending the code_challenge and other details like the client ID and redirect URI.
  3. User Grants Access:

    • The user logs in to Azure Entra ID and grants access.

    • Azure Entra ID then issues an authorization code to the frontend app.

  4. Exchange Authorization Code for Access Token:

    • The frontend app sends the authorization code along with the original code_verifier (not the code_challenge) to the token endpoint.

    • Azure Entra ID verifies the code_verifier against the previously sent code_challenge. If they match, an access token is issued.

  5. Access Token Usage:

    • The frontend app receives the access token and uses it to call protected APIs by adding it to the Authorization header of the request.

This flow prevents attackers from intercepting the authorization code and using it on their own, as the code_verifier is required to complete the token exchange.

How to Implement PKCE in Frontend

To implement PKCE in your frontend (SPA or mobile app):

  • Use libraries like MSAL.js (Microsoft Authentication Library) for Azure AD.

  • The PKCE challenge and token management is automatically handled by these libraries. You just need to configure your app with Azure AD settings (client ID, tenant, redirect URIs).


Spring Boot Project Setup for Azure Entra ID

Configuring Spring Boot to Use Azure Entra ID

In your Spring Boot application, you’ll need to configure it to act as a resource server that validates JWT tokens issued by Azure Entra ID.

Steps for Implementation:

a) Add Dependencies

First, include the required Spring Security OAuth2 dependencies in your pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

b) Configure application.yml for Azure Entra ID

Next, configure your Spring Boot application to point to Azure Entra ID for token validation using the issuer URI:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://login.microsoftonline.com/{tenant-id}/v2.0
           # you can find the issuer-uri in you token
  • The issuer-uri tells the resource server where to retrieve public keys (JWKS) and other token details from Azure AD’s OpenID Connect discovery document.

  • Replace {tenant-id} with your actual Azure AD tenant ID.

c) Understanding How issuer-uri Works

The issuer-uri points to Azure’s OpenID Connect (OIDC) discovery endpoint. When a JWT is received by your application, Spring Security will:

d) Secure Endpoints with Roles and Scopes

You can secure specific endpoints in your application based on user roles or scopes defined in the JWT. For example:

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeRequests(authorizeRequests ->
            authorizeRequests
                .antMatchers("/admin/**").hasRole("ADMIN")
                .antMatchers("/user/**").hasAnyRole("USER", "ADMIN")
                .anyRequest().authenticated()
        )
        .oauth2ResourceServer(OAuth2ResourceServerConfigurer::jwt);
    return http.build();
}
  • The hasRole("ADMIN") or hasAnyRole methods will check the user’s roles that are included in the JWT token.

Conclusion

By following these steps, you’ll be able to:

  1. Authenticate users using Azure Entra ID.

  2. Securely implement PKCE in the frontend to prevent interception attacks.

  3. Integrate Azure Entra ID with your Spring Boot application to verify and authorize API requests.

0
Subscribe to my newsletter

Read articles from Shohanur Rahman directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Shohanur Rahman
Shohanur Rahman

👋 Hey there! I’m Shohanur Rahman! I’m a backend developer with over 5.5 years of experience in building scalable and efficient web applications. My work focuses on Java, Spring Boot, and microservices architecture, where I love designing robust API solutions and creating secure middleware for complex integrations. 💼 What I Do Backend Development: Expert in Spring Boot, Spring Cloud, and Spring WebFlux, I create high-performance microservices that drive seamless user experiences. Cloud & DevOps: AWS enthusiast, skilled in using EC2, S3, RDS, and Docker to design scalable and reliable cloud infrastructures. Digital Security: Passionate about securing applications with OAuth2, Keycloak, and digital signatures for data integrity and privacy. 🚀 Current Projects I’m currently working on API integrations with Spring Cloud Gateway and designing an e-invoicing middleware. My projects often involve asynchronous processing, digital signature implementations, and ensuring high standards of security. 📝 Why I Write I enjoy sharing what I’ve learned through blog posts, covering everything from backend design to API security and cloud best practices. Check out my posts if you’re into backend dev, cloud tech, or digital security!