> Markdown version of [Getting Started](https://vaadin.com/docs/next/tools/sso/getting-started). Section index: [llms.txt](https://vaadin.com/docs/next/tools/llms.txt)
# Getting Started with SSO Kit (Flow) (deprecated since V25.3)
> **Warning:** SSO Kit is deprecated and won’t be available in Vaadin 26.
>
> A replacement is already in place: all of the kit’s major features are now available directly in Spring Security and in Vaadin’s Spring Security integration. See [Migrating from SSO Kit to Spring Security](https://vaadin.com/docs/next/tools/sso/migrating-to-spring-security.md) for how to move an existing application, and which features you have to build yourself.
> **Note: Instructions for Vaadin Flow**
>
> This page guides you in getting started with SSO Kit and Vaadin Flow. See the guide for [getting stated with SSO Kit and Hilla](https://vaadin.com/docs/next/tools/sso/getting-started/hilla.md).
SSO Kit builds upon [Spring Boot](https://spring.io/projects/spring-boot) and [Spring Security](https://spring.io/projects/spring-security). It comes with a starter module that configures the security settings needed to authenticate with an identity provider.
## Add SSO Kit Dependency
To get started, you need to add SSO Kit as a dependency to an application. For example, to add to a Maven project, do something like this:
pom.xml
```xml
com.vaadin
sso-kit-starter
```
Next, you need to set some configuration properties to connect SSO Kit to an OpenID Connect provider. These properties can be added to the `application.properties` file where you define the provider URL and the client registration details, such as credentials and scope.
Provider definition is configured within the `spring.security.oauth2.provider` namespace where you define a key to identify the provider, such as `keycloak`. Then you can use the same key to register the client for that provider within the `spring.security.oauth2.registration` namespace, where you specify client credentials and the requested scope.
The scope is a list of keywords to request the provider for a specific set of information, such as user `profile`, `email` or `roles`. The following is an example of the properties to set so as to enable a Keycloak instance to perform authentication:
application.properties
```properties
spring.security.oauth2.client.provider.keycloak.issuer-uri=https://my-keycloak.io/realms/my-realm
spring.security.oauth2.client.registration.keycloak.client-id= my-client
spring.security.oauth2.client.registration.keycloak.client-secret=very-secret-value
spring.security.oauth2.client.registration.keycloak.scope=profile,openid,email,roles
```
application.yaml
```yaml
spring:
security:
oauth2:
client:
provider:
keycloak:
issuer-uri: https://my-keycloak.io/realms/my-realm
registration:
keycloak:
client-id: my-client
client-secret: very-secret-value
scope:
- profile
- openid
- email
- roles
```
Once you have at least one client configured, you’re ready to secure any views.
## Securing Views
The default configuration redirects requests to any view, to the provider’s login page. You can set which views require authentication, annotating them as described in [Securing Spring Boot Applications: Annotating the View Classes](https://vaadin.com/docs/next/flow/security/enabling-security.md#annotating-the-view-classes).
The following is an example of how you might do this:
`ProfileView.java`
```java
@PermitAll
@Route(value = "private")
public class ProfileView extends VerticalLayout {
// ...
}
```
## Single Sign-On
SSO Kit provides the `SingleSignOnConfiguration` auto-configuration class to set up Vaadin and Spring to allow single sign-on with external identity providers.
> **Note: Customized Security Configuration**
>
> If you need a customized security configuration, you can disable this auto-configuration class by adding its fully-qualified name to the `spring.autoconfigure.exclude` property and define your own configuration class.
The following configuration enables login for the identity providers defined in the application configuration. It instructs the application to accept requests for the login route. It can be configured by setting the `vaadin.sso.login-route` property, which defaults to `/login`. If there is no view defined for this route, Spring auto-generates a page with links to login forms for each of the configured providers.
To redirect users automatically to the provider login form, you can set this property to `/oauth2/authorization/{provider-key}`, where `{provider-key}` is the key used to configure the provider in `application.properties` file.
application.properties
```properties
vaadin.sso.login-route=/oauth2/authorization/keycloak
```
application.yaml
```yaml
vaadin:
sso:
login-route: /oauth2/authorization/keycloak
```
> **Tip: Custom Login Page**
>
> Some providers support a custom theme for their login pages. Find out more in [Theming](https://vaadin.com/docs/next/tools/sso/theming.md).
## Authentication Context
Upon successful authentication, the provider redirects the user back to the protected view. To access the authenticated user’s information (e.g., name, email and roles), Flow provides the `AuthenticationContext` bean that can be used as a view constructor argument. Then you can get the authenticated user with `getAuthenticatedUser(Class userType)`. It returns an `Optional` object containing the user instance if the session has an authenticated user or is empty otherwise.
`ProfileView.java`
```java
public class ProfileView extends VerticalLayout {
public ProfileView(AuthenticationContext authContext) {
authContext.getAuthenticatedUser(OidcUser.class).ifPresent(user -> {
Avatar userAvatar = new Avatar(user.getFullName());
add(userAvatar);
});
}
// ...
}
```
By default, the SSO Kit authenticated user is an instance of `OidcUser`. If your application defines a custom user service to provide your own user type, you can use that type as the `userType` parameter.
## Single Sign-Off
SSO Kit provides two methods for logging out the user, defined by the OpenID Connect specification:
- [RP-Initiated Logout](https://openid.net/specs/openid-connect-rpinitiated-1_0.html)
- [Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html)
### RP-Initiated Logout
RP-Initiated Logout (i.e., Relaying Party, the application) enables the user to logout from the application itself, ensuring the connected provider session is terminated. The `AuthenticationContext` bean provides the `logout()` method to initiate the logout process, programmatically. For example, inside a button click-listener:
`ProfileView.java`
```java
@PermitAll
@Route(value = "private")
public class ProfileView extends VerticalLayout {
public ProfileView(AuthenticationContext authContext) {
add(new Button("Logout", e -> authContext.logout()));
}
// ...
}
```
After a successful logout, the user is redirected to the configured logout redirect route. That can be set with the `vaadin.sso.logout-redirect-route` property:
application.properties
```properties
vaadin.sso.logout-redirect-route=/logout-successful
```
application.yaml
```yaml
vaadin:
sso:
logout-redirect-route: /logout-successful
```
The default value of this property is the application root.
### Back-Channel Logout
Back-Channel Logout is a feature that enables the provider to close user sessions from outside the application. For example, it can be done from the provider’s user dashboard or from another application.
Since SSO Kit 3.1, this feature is enabled by default through Spring Security’s Back-Channel Logout filters. Configure the client on the provider’s dashboard to send logout requests to: `/logout/connect/back-channel/{registration-key}`, where `{registration-key}` is the provider key.
> **Warning: Built-In Implementation Deprecated**
>
> The kit’s built-in Back-Channel Logout implementation, activated with `vaadin.sso.back-channel-logout=true`, is deprecated since SSO Kit 3.1. It’s retained only for backwards compatibility with applications that depend on the legacy behavior. Don’t enable it on new projects: Spring Security’s filters are already active by default and cover the same feature.
`281c3209-efe3-48c8-ada0-0ea8c420757a`