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

VaadinSecurityConfigurer

@EnableWebSecurity
@Configuration
public class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http.with(VaadinSecurityConfigurer.vaadin(), configurer -> {
            configurer.loginView(LoginView.class);
        });
        return http.build();
    }

    @Bean
    public UserDetailsManager userDetailsManager() {
        // WARNING: In-memory users for development only.
        // Use JDBC, LDAP, or OAuth2 in production.
        var user = User.withUsername("user")
                .password("{noop}user")
                .roles("USER")
                .build();
        var admin = User.withUsername("admin")
                .password("{noop}admin")
                .roles("ADMIN")
                .build();
        return new InMemoryUserDetailsManager(user, admin);
    }
}

VaadinSecurityConfigurer.vaadin()

• CSRF — enabled with exemptions for Vaadin internal requests
• Logout — configured with Vaadin-aware logout handlers
• Request cache — Vaadin-specific request cache for redirect after login
• Exception handling — proper error responses for Vaadin requests
• Authorized requests — permits Vaadin framework requests (client engine, push, etc.)
• Navigation access control — enforces view access annotations

LoginForm

@Route(value = "login", autoLayout = false)
@PageTitle("Login")
@AnonymousAllowed
public class LoginView extends Main implements BeforeEnterObserver {

    private final LoginForm login;

    public LoginView() {
        login = new LoginForm();
        login.setAction("login");

        addClassNames(LumoUtility.Display.FLEX,
                LumoUtility.JustifyContent.CENTER,
                LumoUtility.AlignItems.CENTER);
        setSizeFull();
        add(login);
    }

    @Override
    public void beforeEnter(BeforeEnterEvent event) {
        if (event.getLocation()
                .getQueryParameters()
                .getParameters()
                .containsKey("error")) {
            login.setError(true);
        }
    }
}

• autoLayout = false

  — prevents the login view from rendering inside the application's main layout (e.g.,

  AppLayout

  with navigation menu)

• @AnonymousAllowed

  — required so unauthenticated users can access the page

• login.setAction("login")

  — makes the form POST to Spring Security's

  /login

  endpoint

• BeforeEnterObserver

  — checks for the

  ?error

  query parameter that Spring Security adds after a failed login attempt
• Register in SecurityConfig —

  configurer.loginView(LoginView.class)

  tells VaadinSecurityConfigurer which view is the login page

@AnonymousAllowed

@PermitAll

@RolesAllowed("ADMIN")

@DenyAll

Note on

@PermitAll

: Vaadin's use of

@PermitAll

differs from the Jakarta Security standard. In standard Jakarta Security,

@PermitAll

means "anyone, including unauthenticated users" — similar to Vaadin's

@AnonymousAllowed

. In Vaadin,

@PermitAll

means "any authenticated user." Developers familiar with standard Jakarta security may be confused when access is denied to unauthenticated users on a view they explicitly "permitted all" — use

@AnonymousAllowed

for truly public views.

@Route("public")
@AnonymousAllowed
public class PublicView extends VerticalLayout { }

@Route("dashboard")
@PermitAll
public class DashboardView extends VerticalLayout { }

@Route("admin")
@RolesAllowed("ADMIN")
public class AdminView extends VerticalLayout { }

• No annotation on a view —

  @DenyAll

  applies (access denied by default)
• Superclass annotations — inherited from the closest annotated parent class
• Child class annotated — overrides parent class annotations
• Interfaces — annotations on interfaces are not checked
• Layouts are checked independently — both the layout and the view must grant access. A view with

  @PermitAll

  inside a layout with no annotation (default

  @DenyAll

  ) is inaccessible
• Override priority when multiple annotations exist —

  @DenyAll

  >

  @AnonymousAllowed

  >

  @RolesAllowed

  >

  @PermitAll

• application.properties

  — the registration and provider keys change per provider

• oauth2LoginPage()

  URL — use

  /oauth2/authorization/{registrationId}

  where

  {registrationId}

  matches the key in

  application.properties

• Common providers (Google, GitHub, Facebook, Okta) need only

  client-id

  ,

  client-secret

  , and

  scope

• Custom providers (Keycloak, Azure AD) also need

  issuer-uri

  and

  authorization-grant-type

1. Never hard-code credentials — use environment variables or a secrets manager. The

   UserDetailsManager

   with

   {noop}

   passwords is for development only.
2. Annotate every view and layout — views without an access annotation default to

   @DenyAll

   . Layouts are checked independently; both must grant access.
3. Use

   AuthenticationContext

   for logout and user info — it integrates with Spring Security and handles session cleanup correctly. Declare the field

   transient

   .
4. Use

   autoLayout = false

   on the login view — the login view should not render inside the application's main layout.
5. Prefer

   VaadinSecurityConfigurer

   over manual Spring Security config — it handles CSRF, logout, request caching, and exception handling for Vaadin automatically.
6. Externalize OAuth2 credentials — use

   application.properties

   with environment variable references (

   ${GOOGLE_CLIENT_SECRET}

   ) or Spring profiles.
7. Define role constants — create a

   Roles

   class with

   public static final String

   fields to avoid typos in

   @RolesAllowed

   annotations.
8. Leverage Vaadin's server-side security model — UI state lives on the server, so attackers cannot tamper with it from the browser. Combined with annotation-based access control, this provides defense in depth.

1. Forgetting

   autoLayout = false

   on the login view — the login form renders inside the app shell with the navigation menu, which is confusing and may cause access control issues.
2. Forgetting to annotate the layout — a view marked

   @PermitAll

   inside a layout with no annotation (default

   @DenyAll

   ) is inaccessible. Both must independently grant access.
3. Using

   @Secured

   or

   @PreAuthorize

   on views — these Spring Security annotations are not supported on Vaadin views. Use

   @AnonymousAllowed

   ,

   @PermitAll

   ,

   @RolesAllowed

   , or

   @DenyAll

   .
4. Hard-coding passwords in

   SecurityConfig

   — in-memory

   {noop}

   passwords are for prototyping only. Production applications must use JDBC, LDAP, or OAuth2 authentication.
5. Calling

   SecurityContextLogoutHandler

   without redirecting first — the logout handler invalidates the session, so

   UI.getCurrent().getPage().setLocation()

   must happen before the handler call. Prefer

   AuthenticationContext.logout()

   which handles this correctly.
6. Using URL-pattern security for view access control — Vaadin uses a single servlet endpoint for all views; the browser URL is updated client-side but all requests go to the same server endpoint. This means URL-pattern rules in

   HttpSecurity

   (e.g.,

   .requestMatchers("/admin/**").hasRole("ADMIN")

   ) do not control access to Vaadin views. Use annotation-based access control (

   @RolesAllowed

   ,

   @PermitAll

   , etc.) exclusively for view security. URL-pattern rules are still appropriate for non-Vaadin endpoints such as REST APIs.