Отдельный модуль аутентификации пользователей

Question

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

Я ищу информацию о лучших практиках с точки зрения модуля аутентификации пользователей.

Моя текущая идея заключается в следующем:

• Клиент запрашивает модуль UA с данными для входа
• UA модуль проверяет регистрационные данные. Если они действительны, модуль UA создает & хранит токен доступа, связывая токен с уникальным идентификатором проверенного пользователя.
• Токен отправляется обратно клиенту. Клиент сохраняет токен.
• Всякий раз, когда клиент требует аутентификации, он запрашивает модуль UA с токеном. Модуль UA возвращает уникальный идентификатор пользователя, если токен действителен, или возвращает код ошибки, если токен недействителен.

Буду признателен за любую критику в отношении этих методов.

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

Мое понятие состоит в том, что токены должны иметь даты истечения срока годности, связанные с ними, а рабочий процесс должен очищать эти токены с регулярным интервалом. Это правильный путь?

Прокомментируйте! Также приветствуются справочные документы.

Answer 1

Вы можете сохранить токен в поле БД вместе с отметкой времени выпуска с сопоставлением «один к одному» с идентификатором клиента. Поэтому, когда вы переиздаете токен, вы перезаписываете старый. И когда пользователь выходит из системы, обнулите токен.

Когда Пользователь отправляет запрос с маркером, см., Если дата прохода минус (т. Е. Текущее время> время выдачи + период времени истечения срока действия). Это избавит вас от запуска Worker для очистки старых жетонов.