Пример приложения с JWT-токеном

Напишем REST API с использованием JWT-токена (без OAuth2).

В Spring Security JWT-токен используется в OAuth 2 как access token. Он выдается клиенту сервером авторизации, клиент отправляет его при обращении к серверу ресурсов. (А сервер ресурсов проверяет его, обращаясь к серверу авторизации).

Но этот пример — самописная реализация stateless REST API на JWT, единое приложение, которое и выдает, и проверяет токен. И выдает REST API.

На этом примере можно увидеть, как написать свой фильтр авторизации, как сформировать и проверить JWT-токен. Но в реальном проекте этот пример лучше не использовать.

Если нужен JWT без OAuth2, то есть в Spring Boot есть и такое готовое решение.

Задача

В этой статье будет чистый REST-сервис без фронтенда. Подразумевается, что фронтенд написан отдельно: например, на каком-нибудь JavaScript-фрейворке.

Для отправки запросов мы будем использовать программу POSTMAN. Например, для «входа» с именем/паролем и получения JWT-токена. А также для запроса защищенных страниц.

В этом примере наш старый REST-контроллер останется, а настройка Spring Security не особо поменяется — скорее, она дополнится.

Мы добавим в приложение конечную точку /authenticate для аутентификации. Сюда приходят имя и пароль от пользователя. Приложение проверяет пароль, и если он верный, высылает пользователю в ответ JWT-токен.
Во всех дальнейших запросах пользователь обязан высылать в заголовке JWT-токен, наше приложение проверяет подлинность токена в специально написанном фильтре JWTFilter и, если он корректен, пропускает запрос дальше.

Подготовка

REST-контроллер

Итак, наш основной REST-контроллер остается прежним:

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "Hello";
    }

    // сюда доступ разрешен только user и admin 
    @GetMapping("/user")
    public String user() {
        return "User";
    }

    // сюда доступ разрешен только admin 
    @GetMapping("/admin")
    public String admin() {
        return "Admin";
    }

}

Он нужен для того, чтобы запретить к нему доступ и потом разрешить только авторизованным пользователям.

Аутентификация с пользовательским UserDetailsService

Настройка аутентификации такая:

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    @Autowired
    private CustomUserDetailsService userDetailsService;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return NoOpPasswordEncoder.getInstance();
    }

    //... 

    @Override
    public void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth.userDetailsService(userDetailsService);
    }

}

Подробнее об аутентификации с UserDetailsService есть статья.

Если кратко, мы переопределяем метод loadUserByUsername(), чтобы Spring Security понимал, как взять пользователя по его имени из хранилища. Имея этот метод, SS может сравнить переданный пароль с настоящим и аутентифицировать пользователя (либо не аутентифицировать).

CustomUserDetailsService:

@Service
public class CustomUserDetailsService implements UserDetailsService {
    @Autowired
    private MyUserRepository dao;
    @Override
    public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException {
        MyUser myUser= dao.findByLogin(userName);
        if (myUser == null) {
            throw new UsernameNotFoundException("Unknown user: "+userName);
        }
        UserDetails user = User.builder()
                .username(myUser.getLogin())
                .password(myUser.getPassword())
                .roles(myUser.getRole())
                .build();
        return user;
    }
}

Пользователи хранятся в In-Memory базе данных H2. Работаем через Hibernate.

Модель пользователя:

@Entity
public class MyUser {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    long id;
    private String login;
    private String password;
    private String position;
    private String role;
  
   // геттеры/сеттеры

}

И репозиторий:

@Repository
public interface MyUserRepository extends JpaRepository<MyUser, Long> {
    MyUser findByLogin(String login);
}

А данными заполняем базу на старте приложения с помощью data.sql (этот файл надо положить в папку /resources, а в application.yml включить его запуск):

insert into my_user(login, position, password, role) values('user', '1', 'password', 'USER');
insert into my_user( login, position, password, role) values('admin', '2', 'password', 'ADMIN');

А теперь перейдем собственно в JWT-токену.

Библиотека для работы с JWT-токеном

Для работы с JWT добавим Maven-зависимость:

        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>

Для работы с JWT-токеном уже написаны утилиты, так что используем готовую. В ней есть метод формирования токена, методы извлечения имени пользователя и других данных. Метод формирования токена изменим так, чтобы записывать в токен еще список authorities в виде клейма authorities.

Во всех методах извлечения данных JWT-токен заодно проверяется на предмет не истек ли он, и валидна ли подпись.

Эти методы утилиты нам пригодятся:

@Service
public class JWTUtil {

    @Value("${jwt.secret}")
    private String SECRET_KEY;

    @Value("${jwt.sessionTime}")
    private long sessionTime;

    // генерация токена (кладем в него имя пользователя и authorities)
    public String generateToken(UserDetails userDetails) {
        Map<String, Object> claims = new HashMap<>();
        String commaSeparatedListOfAuthorities=  userDetails.getAuthorities().stream().map(a->a.getAuthority()).collect(Collectors.joining(","));
        claims.put("authorities", commaSeparatedListOfAuthorities);
        return createToken(claims, userDetails.getUsername());
    }
    
    //извлечение имени пользователя из токена (внутри валидация токена)
    public String extractUsername(String token) {
        return extractClaim(token, Claims::getSubject);
    }

    //извлечение authorities (внутри валидация токена)
    public String extractAuthorities(String token) {
       return extractClaim(token, claims -> (String)claims.get("authorities"));
    }
   // другие методы
}

Это была подготовка. Перейдем, наконец, к написанию своего кода, касающегося JWT.

Конечная точка аутентификации для выдачи JWT-токена

Тут собственно выдается JWT-токен. Пользователь делает POST-запрос с именем и паролем по адресу /authenticate, а в ответ получает сгенерированынй токен. Токен генерится методом generateToken() из утилиты выше.

@RestController
public class AuthenticationController {


    @Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private JWTUtil jwtTokenUtil;


    @PostMapping("/authenticate")
    @ResponseStatus(HttpStatus.OK)
    public AuthResponse createAuthenticationToken(@RequestBody AuthRequest authRequest) {
        Authentication authentication;
        try {
            authentication = authenticationManager.authenticate(new UsernamePasswordAuthenticationToken(authRequest.getName(), authRequest.getPassword()));
            System.out.println(authentication);
        } catch (BadCredentialsException e) {
            throw new ResponseStatusException(HttpStatus.UNAUTHORIZED, "Имя или пароль неправильны", e);
        }
        // при создании токена в него кладется username как Subject claim и список authorities как кастомный claim
        String jwt = jwtTokenUtil.generateToken((UserDetails) authentication.getPrincipal());

        return new AuthResponse(jwt);
    }
}

Запрос имеет такой формат:

public class AuthRequest {
    private String name;
    private String password;
    // геттеры сеттеры
}

А ответ такой:

public class AuthResponse {

    private String jwtToken;

   // геттер и сеттер
}

Если имя и пароль верные, токен возвращается в AuthResponse, а если нет — выбрасывается исключение и на фронтенд приходит сообщение об ошибке.

Фронтенд сохраняет у себя JWT-токен, и потом использует его при каждом запросе.

Немного о «разлогине»

Если пользователь хочет выйти, токен должен быть уничтожен на фронтенде. На бэкенде (в нашем Spring приложении) он продолжит действовать до истечения своего срока. А вообще теоретически можно сделать черный список токенов, но не в этом примере.

Еще: чтобы сделать токены сразу всех пользователей недействительными, достаточно поменять секретный код. Но тогда разлогинены будут все сразу.

В этом проблема JWT-токена — нужны обходные пути для того, чтобы сделать его недействительным.

Перейдем ко второй принципиальной части — фильтру, проверяющему токен при каждом запросе.

Фильтр, проверяющий JWT-токен при каждом запросе

Итак, JWT-токен выдан, клиент его нам отправляет при каждом запросе, надо этот токен при каждом запросе проверять (и извлекать из него имя пользователя). Для этого напишем фильтр JWTFilter. Он расширяет OncePerRequestFilter и происходит в нем следующее:

При каждом запросе из заголовка Authorization берем JWT-токен (он начинается с префикса «Bearer«).
Извлекаем из него имя пользователя (claim subject) и список authorities (claim authorities). Оба клейма мы записывали в токен при его генерации в контроллере.
Одновременно при извлечении claims проверяется валидность токена. Для этого не надо делать никаких запросов в базу: достаточно самого токена и jwt.secret (прописанного в application.yml). На основе этого секрета токен генерился, и на основе него он потом каждый раз проверяется с помощью хеш-функции (это делает библиотека jjwt).
Если все ок, то имея имя пользователя и список authorities (извлеченные в п.2), создаем объект Authentication (точнее, его подкласс UsernamePasswordAuthenticationToken). И устанавливаем объект Authentication в SecurityContext. Так нужно для Spring Security.
Если с токеном не все ок, то в п. 2-3 выбросился исключение, и фильтр не пропустит запрос в контроллер к защищенному /url.

@Component
public class JWTFilter extends OncePerRequestFilter {

    @Autowired
    private JWTUtil jwtUtil;

    @Autowired
    CustomUserDetailsService userDetailsService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
            throws ServletException, IOException {

        final String authorizationHeader = request.getHeader("Authorization");

        String username = null;
        String jwt = null;

        if (authorizationHeader != null && authorizationHeader.startsWith("Bearer ")) {
            jwt = authorizationHeader.substring(7);
            //если подпись не совпадает с вычисленной, то SignatureException
            //если подпись некорректная (не парсится), то MalformedJwtException
            //если время подписи истекло, то ExpiredJwtException
            username = jwtUtil.extractUsername(jwt);
        }


        if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) {

            String commaSeparatedListOfAuthorities = jwtUtil.extractAuthorities(jwt);
            List<GrantedAuthority> authorities = AuthorityUtils.commaSeparatedStringToAuthorityList(commaSeparatedListOfAuthorities);
            UsernamePasswordAuthenticationToken usernamePasswordAuthenticationToken =
                    new UsernamePasswordAuthenticationToken(
                            username, null, authorities);

            SecurityContextHolder.getContext().setAuthentication(usernamePasswordAuthenticationToken);

        }
        chain.doFilter(request, response);
    }

}

Настройка авторизации: собираем все вместе

Тут все как раньше, но только:

отключаем csrf,
отключаем сессии
и добавляем наш фильтр JWTFilter перед фильтром UsernamePasswordAuthenticationFilter.

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Autowired
    private JWTFilter jwtFilter;

   // еще поля и методы
 
    // Бин AuthenticationManager используется в контроллере аутентификации (см. выше)

    @Bean
    public AuthenticationManager authenticationManagerBean() throws Exception {
        return super.authenticationManagerBean();
    }

    // тут отключаем сессии и добавляем фильтр JWTFilter 

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.csrf().disable()
                .authorizeRequests()
                .antMatchers("/authenticate").permitAll()
                .and().authorizeRequests().antMatchers("/user/**").hasAnyAuthority("ROLE_USER", "ROLE_ADMIN")
                .and().authorizeRequests().antMatchers("/admin/**").hasAuthority("ROLE_ADMIN")
                .and().sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);

        http.addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class);
    }
}

Проверка

Запустим приложении и убедимся, что все работает.

Получение JWT-токена

Отправим POST-запрос нужного формата по адресу /authencate:

Отправка запроса с JWT-токеном

Токен получен, теперь с ним можно попасть на защищенную страницу. Для этого добавим его к запросу /user в заголовок Authorization.

При этом выберем тип Bearer-токен — это значит, что префикс Bearer будет добавлен к токену.

А теперь с ним запрашиваем защищенный url /user

Как видно, страница /user получена.

Вид JWT-токена

Если декодировать токен на сайте https://jwt.io/, то в нем видны наши добавленные клеймы sub (имя пользователя) и authorities:

Остальные два клейма:

exp — когда истекает токен
iat -когда выпущен токен

Исходный код

Он находится на GitHub.