Introduction

If BearerTokenAccessDeniedHandler cannot be found at compile time or runtime, the problem is usually dependency wiring, not the class itself. In Spring Security, that class belongs to the OAuth 2.0 resource server support, so missing the resource-server module or mixing incompatible Spring Security versions is the most common cause.

Where the class comes from

BearerTokenAccessDeniedHandler lives in the Spring Security resource server package:

org.springframework.security.oauth2.server.resource.web.access

It is part of the OAuth 2.0 resource server support introduced in Spring Security 5.1. That means plain spring-security-web by itself is not enough if your configuration expects bearer-token resource-server classes.

Add the right dependency

In a Spring Boot application, the simplest fix is usually the Boot starter:

1<dependency>
2  <groupId>org.springframework.boot</groupId>
3  <artifactId>spring-boot-starter-oauth2-resource-server</artifactId>
4</dependency>

If you are managing Spring Security modules manually, include the resource-server artifact explicitly:

1<dependency>
2  <groupId>org.springframework.security</groupId>
3  <artifactId>spring-security-oauth2-resource-server</artifactId>
4</dependency>

For JWT support, Spring Security documentation also separates JOSE support into its own module, so JWT-based resource servers often need:

1<dependency>
2  <groupId>org.springframework.security</groupId>
3  <artifactId>spring-security-oauth2-jose</artifactId>
4</dependency>

Avoid version mismatches

A frequent real-world cause is mixing Boot-managed Spring Security versions with manually pinned module versions. For example, if Boot brings one Spring Security version but a transitive dependency pulls another, you can get:

• compile-time symbol not found
• runtime ClassNotFoundException
• runtime NoClassDefFoundError

The safest rule is:

• let Spring Boot manage Spring Security versions when using Boot
• avoid manually overriding individual Spring Security module versions unless you must

That keeps the resource server, web, config, and JOSE modules aligned.

A typical configuration that expects the class

A bearer-token resource server configuration often looks like:

1@Bean
2SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
3    http
4        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated())
5        .oauth2ResourceServer(oauth2 -> oauth2.jwt());
6    return http.build();
7}

When this DSL is active, Spring Security configures bearer-token handling internally. If the required resource-server classes are missing from the classpath, the application cannot wire that security chain correctly.

Diagnose the classpath, not just the import

If the import resolves in the IDE but the app fails at runtime, inspect the resolved dependency tree:

mvn dependency:tree

or:

./gradlew dependencies

You are looking for:

• missing spring-security-oauth2-resource-server
• duplicated Spring Security versions
• exclusions that removed required modules

That is usually more productive than editing Java config blindly.

Common Pitfalls

The biggest mistake is assuming all bearer-token support comes with the base Spring Security dependencies. Resource server support is a separate module.

Another mistake is mixing Spring Boot dependency management with hand-pinned Spring Security artifacts. That often creates subtle classpath conflicts.

Developers also forget that JWT resource servers typically need JOSE support in addition to the core resource-server module.

Finally, do not focus only on the import statement. A runtime ClassNotFoundException is usually about dependency resolution, not Java syntax.

If the project recently upgraded Spring Boot, recheck every custom security dependency afterward. Version drift often appears only after one module moves ahead of the rest of the managed stack.

Once the classpath is fixed, keep the security configuration minimal until the app starts cleanly. It is much easier to verify the dependency problem first and then reintroduce custom access-denied handling than to debug both at the same time.

Summary

• 'BearerTokenAccessDeniedHandler belongs to Spring Security's OAuth 2.0 resource server support.'
• Add spring-boot-starter-oauth2-resource-server in Boot apps or spring-security-oauth2-resource-server in manual setups.
• Include JOSE support as well when using JWT resource servers.
• Keep Spring Security module versions aligned, especially under Spring Boot.
• Inspect the dependency tree if the class is missing at runtime even though the code compiles.