Собственный механизм авторизации с использованием токенов на Spring Boot и Spring Security

В Spring Security заложено множество возможностей и даже готовых решений в плане авторизации и аутентификации. Но, к сожалению, не всегда стандартный функционал отвечает бизнес требованиям. Поэтому создание собственных механизмов авторизации не такое уж и редкое явление.

В этой статье мы рассмотри создание собственного механизма авторизации на основе токенов.

Сразу отметим, что несмотря на название статьи мы не будем рассматривать в ней генерацию и конкретные механизмы валидации.

Это связано с тем, что:

  1. Существует целый ряд алгоритмов и подходов для получения токенов (JWT не единственное возможное решение!);
  2. Механизм валидации токена часто определяется не только и даже не столько типом токена, сколько бизнес логикой проекта.

Поэтому, чтобы не вдаваться в излишние подробности, в статье мы заменим валидацию её заглушкой.

Надеюсь на понимание!

Общее описание компонентов системы

Как известно система авторизации и аутентификации Spring Security базируется на четырёх основных компонентах:

  • Фильтр запроса, который получает токен из соответствующего заголовка запроса и при необходимости выполняет простейшие первичные проверки;
  • Объект Authentication, который содержит данные о токене и правах пользователя (работа с правами в статье не рассматривается);
  • Менеджер аутентификации (AithenticationManager), который реализует основную логику;
  • Класс конфигурации, который выполняет соответствующую настройку Spring Security, включая подключение вышеназванных компонентов.

Рассмотрим их реализацию.

Объект Authentication

В нашем случае это класс наследник абстрактного класса AbstractAuthenticationToken.

Класс довольно простой. Всё, что нам нужно, это сохранить в нём наш токен, как это показано ниже:

Фильтр запроса

Фильтр будет наследником класса AbstractAuthenticationProcessingFilter.

В фильтре мы будем получать токен из соответствующего заголовка HTTP запроса и проверять не равен ли он null (последнее означает отсутствие токена).

Менеджер аутентификации

Реализует интерфейс AuthenticationProvider. В нём, по сути, и происходит основная проверка.

Класс конфигурации

Является наследником класса WebSecurityConfigurerAdapter.

Здесь мы настраиваем Spring Sequrity. Указываем, какие URL требуют авторизации, а какие нет. Подключаем вышеописанные компоненты. Настраиваем сессию.

Обратите внимание, что при создании собственного механизма авторизации, необходимо переопределять оба метода configure, чтобы добавить не только фильтр, но и менеджер аутентификации. Иначе ничего работать не будет (во всяком случае правильно).

Также следует отключить сохранение состояния для сессии, как это показано выше (sessionCreationPolicy(SessionCreationPolicy.STATELESS).  Иначе при попытке авторизоваться с правильным токеном можно получить ошибку 500 (Internal Server Error).

Резюме

В этой статье мы создали, по сути, общий механизм, который может использоваться для авторизации и аутентификации с использованием любых токенов и в соответствии с любой бизнес логикой.

Всё, что остаётся сделать, так это внести соответствующие доработки для реализации проверки как самого токена, так и прав пользователя. Но, это уже темы для других статей.

Добавить комментарий

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