Комментарии 7
Помню у заказчика был этот blitz, хотели на своем стенде разработки его развернуть, но на тот момент с этим были нюансы. Отрадно, что сейчас на сайте появилась возможность скачать дистрибутив.
Галопом по европам )
А что происходит, когда сторонняя система получает от пользователя токен? Как она определяет годность (валидность) токена и откуда берется модель соотв пользователя?
При получении токена от пользователя, система проверяет его (токена) наличие в таблице со списком токенов в БД системы и то, что время жизни токена не закончилось.
Если все ок, то выполняется дальнейшая логика, если нет, то возвращается 401 ответ и текст ошибки.
В таблицу БД системы токен попадает из blitz при авторизации пользователя
Не понимаю. в прикладном сервисе имеется таблица с токенами, выданными сервисов аутентификации? Или мы сейчас монолит обсуждаем?
Да, в прикладном сервисе имеется таблица с токенами, выданными сервисом аутентификации. Хранятся только действующие токены. Сделано для того, чтобы не ходить при каждом запросе пользователя к API на сервис аутентификации, а ходить только тогда, когда время жизни токена истечёт
А если в сервисе auth пользователя деактивировали, он продолжает ходить пока токен не протухнет или ...?
Да, если в сервисе auth пользователя деактивировали, он продолжает ходить пока токен не протухнет.
Но время жизни access_token обычно небольшое, в данном проекте 5 минут. Затем access_token обновляется в сервисе auth с помощью refresh_token. И если пользователь деактивирован, то обновить токен не получится и пользователь получит ошибку доступа.
Авторизация пользователей в системе через сервер аутентификации Blitz Identity Provider (bitrix + slim + react)