Документация Epos Next

Authentication Flow

Все про авторизацию

Кратко

Используется две системы авторизации: одна для оригинального эпоса, вторая для next. Клиенты (web и mobile) используют только next авторизацию, с оригинальной системой взаимодействует только API. Оригинальная система построена на одном единственном токене с часом жизни. Выдается при авторизации в оригинальный ЭПОС, используется для любого рода взаимодействия. Next авторизация работает на JWTopen in new window токенах c временью жизни в 10 минут и 1 год.

Flow

Тут рассмотрим как оба этих токена используется в системе

Логин в первый раз

"В первый раз" – означатет что юзер никогда раньше не использовал epos некст ни с одного из устройств

  1. Юзер вводит email и пароль на клиенте
  2. Email и пароль улетают в API, в AuthControlleropen in new window
  3. API смотрит нет ли пользователя с таким email в БД (в данном сценарии его там нет)
  4. Если не нашел юзера – стучись в API эпоса и получай все данные о нем
  5. После получения в БД сохраняется entity user'a, а в redis auth_token (тот самый, с 10 минутной жизнью и оргромными возможностями). auth_token сам удалится из redis'a через 10 минут
  6. Cамостоятельно генерирует JWT токены и возвращает их клиенту (Оригинальный эпос не знает и не признает эти токены. В будующем будут использоватся для взаимодействия с эпос некст)

Логин не в первый раз

Если юзер когда-либо уже пользовался эпосом некст, не обязательно с этого устройства

  1. Юзер вводит email и пароль на клиенте
  2. Email и пароль улетают в API, в AuthControlleropen in new window
  3. API смотрит нет ли пользователя с таким email в БД (в данном сценарии находит)
  4. Cамостоятельно генерирует JWT токены и возвращает их клиенту (Оригинальный эпос не знает и не признает эти токены. В будующем будут использоватся для взаимодействия с эпос некст), вместе с моделькой юзера, которую он достал из БД. Тут никаких запросов к оригинальному эпосу нет!

Любой запрос на получение оригинальных данных

Под получением данных имеется ввиду все, что нужно подтянуть из оригинального эпоса. Это рассписание и ДЗ.

Для выполнения этого типа запроса юзер должен иметь валидный не просроченый access JWT токен (Который не из оригинального эпоса, а который мы сами себе подписали с временью жизни в 10 минут)

  1. Юзер стучится в API и передает access JWT токен
  2. API проверяет access JWT токен на валидность (Если не валиден, возвращает 401), и забывает о существовании access JWT токена (в том плане, что больше в этом запросе он ничего делать не будет, он все еще валидный)
  3. API смотрит в redis auth_token (который нам выдал оригинальный эпос). Если находит – юзает его дальше. Если не находит, то берет из БД email и пароль юзера, и заново проводит авторизацию, после которой имеет новый auth_token (ну и кладет его в redis)
  4. API делает запрос, используя полученный на предыдущем шаге auth_token и возвращает ответ юзеру

Summary

Есть два типа токенов. Первый это auth_token оригинального эпоса, используется для взаимодействия API с оригинальным эпосом. Второй это JWT токены, используеются ля взаимодействия API с клиентами (web и mobile)