OAuth2 Authentication
Vaadin applications can be configured to authenticate users using an existing account at an OAuth 2.0 Provider (e.g., GitHub) or at an OpenID Connect 1.0 Provider (e.g., Google).
This page focuses on how to configure a Spring Boot project to integrate OAuth2 authentication in Vaadin. It assumes you’re familiar with setting up Spring Security with Vaadin. For detailed information about Spring Security and OAuth2, consult the Spring documentation.
Application Configuration
To start, add the spring-security-oauth2-client dependency to your project. When using Spring Boot, use the following starter:
Source code
Maven
Maven<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>Gradle
GradleNext, add the OAuth2 provider settings to the application’s configuration file. The following example configuration integrates a Keycloak OAuth2 provider. To setup a test environment, refer to the Keycloak Integration in Vaadin SSO Kit documentation.
Source code
application.properties
spring.security.oauth2.client.registration.keycloak.provider=keycloak
spring.security.oauth2.client.registration.keycloak.client-id=my-client-id
spring.security.oauth2.client.registration.keycloak.client-secret=<<client secret>>
spring.security.oauth2.client.registration.keycloak.authorization-grant-type=authorization_code
spring.security.oauth2.client.registration.keycloak.scope=openid,profile
spring.security.oauth2.client.provider.keycloak.issuer-uri=http://keyclok.local:8180/realms/my-appapplication.yaml
For integration with other OAuth2 providers, refer to the Spring Security documentation.
Enable OAuth2 Login in Vaadin
To enable OAuth2 login in a Vaadin application, use the VaadinSecurityConfigurer class and configure the login page and post-logout redirect URI using the oauth2LoginPage method.
Besides the HttpSecurity instance, there are two method parameters:
-
Login Page: The URI capable of initiating the authentication request. Usually, it’s
/oauth2/authorization/{registrationId}, whereregistrationIdrefers to the client registered in the application configuration file. -
Post Logout Redirect URI: The location where the user is redirected after logout.
The post logout redirect URI can be expressed as a relative or absolute URI, or as a template. The supported URI template variables are {baseScheme}, {baseHost}, {basePort}, {basePath}, and {baseUrl} — which is the same as {baseScheme}://{baseHost}{basePort}{basePath}.
Source code
Enable OAuth Login in VaadinSecurityConfigurer
@Configuration
class SecurityConfiguration {
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http.with(VaadinSecurityConfigurer.vaadin(), configurer -> {
configurer.oauth2LoginPage(
"/oauth2/authorization/keycloak", 1
"{baseUrl}/session-ended" 2
);
});
return http.build();
}
}Enable OAuth Login in VaadinSecurityConfigurer
-
Login page for initiating OAuth2 login with the Keycloak client.
-
Post logout redirect URI uses a template to resolve dynamically the URL.
The oauth2LoginPage(String) method is a shortcut that defaults the post-logout redirect URL to {baseUrl}.
Mapping Keycloak Roles to Authorities
Keycloak puts a user’s roles into the access token instead of the ID token, so Spring Security’s default OidcUserService never sees them: @RolesAllowed("admin") and hasRole("admin") don’t match a Keycloak role named admin.
Call keycloakRoleMapping next to oauth2LoginPage to decode the access token and turn its roles into granted authorities:
Source code
Java
@Configuration
class SecurityConfiguration {
@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http.with(VaadinSecurityConfigurer.vaadin(), configurer -> {
configurer.oauth2LoginPage("/oauth2/authorization/keycloak")
.keycloakRoleMapping();
});
return http.build();
}
}Java
This maps the realm roles from the realm_access claim, the roles that resource_access grants for the current client ID, and the token’s scopes as SCOPE_-prefixed authorities. Roles that resource_access grants to other clients are ignored.
keycloakRoleMapping only takes effect together with oauth2LoginPage and its overloads, and it sets the OidcUserService that this security filter chain uses to load the authenticated user. An application that configures its own OidcUserService should leave keycloakRoleMapping off and install the mapper on that service directly instead:
Source code
Java
var oidcUserService = new OidcUserService();
oidcUserService.setOidcUserConverter(new KeycloakOidcUserMapper());EF8F6AC3-BE67-4BE2-9A78-C371C1D4B9FD