Fix Java Spring Boot Microsoft Entra ID Sign-In Errors

This is where most Azure Java developer identity setups go wrong from the start. A single wrong selection during app registration causes failures that look like Spring Boot bugs but are actually portal configuration mismatches.

Sign into the Azure portal, click the top-left menu, and navigate to Microsoft Entra ID. In the left navigation pane, select App Registrations, then click New registration.

On the registration form, fill in the following exactly:

• Name: Something descriptive, like java-spring-webapp-auth. This is display-only but keep it meaningful for your team.
• Supported account types: Select "Accounts in this organizational directory only", this is the single-tenant option. If your app is multi-tenant, this choice changes, but for most enterprise Java apps you want single tenant.
• Redirect URI: Choose "Web" from the dropdown, then enter http://localhost:8080/login/oauth2/code/ exactly as written.

Click Register. Once the registration is created, you land on the overview page. From here, copy two values into a text file, you'll need them shortly:

• Application (client) ID
• Directory (tenant) ID

Then click Certificates & secrets in the left menu, choose Client secrets, and click New client secret. Give it a description, set the expiry period (12 or 24 months is typical), and click Add. Copy the secret Value immediately, once you navigate away from this page, the full secret is hidden forever and you'll have to create a new one.

If it worked: you should now have three strings, a client ID (GUID format), a tenant ID (GUID format), and a client secret (a long alphanumeric string). These three values go directly into your Spring Boot configuration. If you see any errors in the portal during registration, check that your Azure account has the Application Administrator or Global Administrator role on the Entra ID tenant.

Now let's get the right dependency into your Maven project. The Microsoft Entra ID Spring Boot Starter is the official Microsoft library that bridges Spring Security and the OpenID Connect sign-in flow, it handles token acquisition, validation, and session management so you don't have to wire all that up yourself.

Open your pom.xml and add the Azure Spring Boot Bill of Materials (BOM) and the Entra ID starter dependency:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.azure.spring</groupId>
      <artifactId>spring-cloud-azure-dependencies</artifactId>
      <version>5.19.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>com.azure.spring</groupId>
    <artifactId>spring-cloud-azure-starter-active-directory</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-client</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

Note: spring-boot-starter-oauth2-client is a required companion, the Entra ID starter builds on top of Spring Security's OAuth2 client support. If you omit it, the auto-configuration won't activate and you'll get a confusing NoSuchBeanDefinitionException at startup instead of a clear missing-dependency error.

Run mvn dependency:tree after updating the POM to confirm both spring-cloud-azure-starter-active-directory and msal4j (the Microsoft Authentication Library for Java) appear in the dependency graph. If msal4j is missing, your version of the starter BOM may be outdated.

After the dependency resolves cleanly, you should be able to run mvn spring-boot:run without compilation errors before you've even added the configuration properties.

This step is where the majority of MSAL for Java token acquisition errors originate. The property names are long and the documentation shows slightly different naming across versions, which leads to silent misconfiguration, the app starts fine but authentication simply never completes.

Open src/main/resources/application.properties and add the following block, substituting your actual values from Step 1:

# Microsoft Entra ID configuration
spring.cloud.azure.active-directory.enabled=true
spring.cloud.azure.active-directory.profile.tenant-id=<YOUR_TENANT_ID>
spring.cloud.azure.active-directory.credential.client-id=<YOUR_CLIENT_ID>
spring.cloud.azure.active-directory.credential.client-secret=<YOUR_CLIENT_SECRET>

# Optional but recommended: explicitly set the redirect URI
spring.cloud.azure.active-directory.redirect-uri-template=http://localhost:8080/login/oauth2/code/

A few things I want to flag from real-world Java Spring Boot OIDC login not working reports:

• The property key prefix changed between older versions of the library. Older guides use azure.activedirectory.*. Current versions use spring.cloud.azure.active-directory.*. If your app was copied from an older tutorial, this mismatch will silently break things because Spring Boot won't throw an error on unrecognized properties, it just ignores them.
• Never commit your client-secret to source control. Use environment variables or Azure Key Vault. Set the property as: spring.cloud.azure.active-directory.credential.client-secret=${AZURE_CLIENT_SECRET} and export AZURE_CLIENT_SECRET as an environment variable before starting the app.
• The spring.cloud.azure.active-directory.enabled=true line is not optional, without it, the auto-configuration class won't activate on some versions of the starter.

Once properties are set, start the app with mvn spring-boot:run and navigate to http://localhost:8080. If configuration is correct, Spring Security will immediately redirect you to the Microsoft login page. A failure at this point means either the tenant ID is wrong (you'll get an AADSTS error in the browser) or the Spring Security filter chain isn't picking up the OAuth2 client configuration.

Getting the redirect to the Microsoft login page is only half the battle. Once the user signs in and the Microsoft identity platform Java developer flow returns an ID token, your app needs to know which routes require authentication and what to do with the token claims.

Create a security configuration class:

import com.azure.spring.cloud.autoconfigure.aad.AadWebSecurityConfigurerAdapter;
import org.springframework.security.config.annotation.method.configuration.EnableGlobalMethodSecurity;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.context.annotation.Configuration;

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class SecurityConfig extends AadWebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        super.configure(http);
        http.authorizeRequests()
            .antMatchers("/public/**").permitAll()
            .anyRequest().authenticated();
    }
}

Extending AadWebSecurityConfigurerAdapter (provided by the Entra ID Spring Boot Starter) is critical. If you extend the generic Spring Security WebSecurityConfigurerAdapter instead, you lose the OIDC logout flow and ID token validation that the Entra ID adapter sets up automatically. This is a subtle bug, your app will accept the login redirect and token, but logout won't properly invalidate the Entra ID session, leaving users logged in on the Microsoft side even after clicking your app's logout button.

Once the user authenticates, you can access their details from the security context:

import org.springframework.security.oauth2.client.authentication.OAuth2AuthenticationToken;
import java.security.Principal;

@GetMapping("/profile")
public String profile(Model model, Principal principal) {
    OAuth2AuthenticationToken token = (OAuth2AuthenticationToken) principal;
    model.addAttribute("userName", token.getPrincipal().getAttribute("name"));
    model.addAttribute("userEmail", token.getPrincipal().getAttribute("preferred_username"));
    return "profile";
}

If this view returns null values for name or preferred_username, it means the ID token claims aren't being passed through. Check that the OpenID Connect scope includes profile, add spring.cloud.azure.active-directory.authorization-clients.graph.scopes=https://graph.microsoft.com/User.Read to your properties if you need richer user profile data via Microsoft Graph.

If your app needs to authenticate customers (not just internal employees) using Azure AD B2C Java authentication setup, the configuration is meaningfully different from standard Entra ID. I see a lot of developers copy a standard Entra ID config and wonder why B2C sign-in user flows don't work, these are separate services with different endpoints and property keys.

For Azure AD B2C, your application.properties needs to reference the B2C tenant and the specific user flow or custom policy name:

spring.cloud.azure.active-directory.b2c.enabled=true
spring.cloud.azure.active-directory.b2c.base-uri=https://<YOUR_B2C_TENANT>.b2clogin.com/<YOUR_B2C_TENANT>.onmicrosoft.com/
spring.cloud.azure.active-directory.b2c.credential.client-id=<YOUR_B2C_CLIENT_ID>
spring.cloud.azure.active-directory.b2c.credential.client-secret=<YOUR_B2C_CLIENT_SECRET>
spring.cloud.azure.active-directory.b2c.user-flows.sign-up-or-sign-in=B2C_1_signupsignin
spring.cloud.azure.active-directory.b2c.login-flow=sign-up-or-sign-in

Note that B2C uses a completely separate App Registration, you cannot reuse the same registration you created in Step 1 for both standard Entra ID and B2C. They live in different tenant types.

B2C also lets you integrate external social identity providers like Google, Facebook, or Apple. These are configured entirely in the Azure portal under your B2C tenant's Identity Providers blade, you don't need to change any Java code for the social provider connections themselves. The Spring Boot app just sends the user to the B2C login page and B2C handles brokering the social login, returning a B2C-issued token to your app. This is one of the design wins of the Microsoft identity platform for Java developers, your application code stays the same regardless of whether the end user authenticated with their Microsoft account, Google, or a local username-password flow.

If B2C login returns a generic AADB2C error code (they look like AADB2C90006, AADB2C90208), check the B2C user flow run page in the Azure portal, it provides a test interface that shows exactly what token would be issued and surfaces configuration errors directly.