> Markdown version of [Spring Security Integration](https://vaadin.com/docs/next/flow/testing/browserless/spring-security). Section index: [llms.txt](https://vaadin.com/docs/next/flow/llms.txt)

# Spring Security Integration

`SpringBrowserlessTest` integrates the simulated Vaadin environment with Spring Security test authentication. By default, authentication from Spring Security test annotations is available before UI creation and initial navigation, so route access checks observe the test user.

## <a id="navigation-access-control"></a>Navigation Access Control

`NavigationAccessControl` must be registered as a UI `BeforeEnterListener` for view protection to apply. Spring Boot tests normally receive this setup automatically. A restricted Spring context may need explicit registration through a `VaadinServiceInitListener`, or a `NavigationAccessControl` bean together with `NavigationAccessControlInitializer`.

## <a id="authentication-sources"></a>Authentication Sources

Spring Security test annotations such as `@WithMockUser`, `@WithAnonymousUser`, and `@WithUserDetails` select authentication for individual test methods. They require `spring-security-test` on the test classpath. `@WithUserDetails` uses a `UserDetailsService` from the selected application context.

Authentication established in the test method, or with `setupBefore = TestExecutionEvent.TEST_EXECUTION`, arrives after initial navigation. The rendered view is not replaced automatically; another navigation applies access control to the new authentication. See [Authentication Applied During a Test](https://vaadin.com/docs/next/flow/testing/browserless/environment-differences.md#authentication-applied-during-a-test) for the lifecycle contract and the linked test example.

## <a id="application-context-isolation"></a>Application Context Isolation

Bean overrides such as `@MockitoBean` and `@MockBean` change Spring’s test context cache key. When multiple contexts are used in a suite, the browserless security integration can fail to apply the simulated user during navigation, including in other test classes. For a practical service-substitution approach, see [Using a Reduced Application Context](https://vaadin.com/docs/next/building-apps/testing/browserless/speed-up-tests.md#using-a-reduced-application-context).

For simultaneous authenticated users, the [application context API](https://vaadin.com/docs/next/flow/testing/browserless/multi-user.md) maintains security state per user.

For a worked example, see [Test View Access Control](https://vaadin.com/docs/next/building-apps/testing/browserless/test-view-access.md).

## <a id="session-fixation-protection"></a>Session Fixation Protection (since V25.3)

Spring Security gives the session a new ID when a user authenticates, and an application without Spring Security does the same by calling `HttpServletRequest.changeSessionId()` after a successful login. The mocked request performs that rotation instead of refusing it, so a test can drive a login flow that protects against session fixation.

The session itself survives the rotation: the attributes stay, and so does the `VaadinSession` bound to it. Only the ID changes.

```java
String idBeforeLogin = VaadinSession.getCurrent().getSession().getId();

// Log in through the application's own flow

Assertions.assertNotEquals(idBeforeLogin,
        VaadinSession.getCurrent().getSession().getId());
```

`2A8B3F1E-9C47-4D5A-B621-8E3F2A7C9D10`