KL
Только тут нужно проверку делать, чтобы бесконечно не редиректить
Size: a a a
2020 October 10
KL
Ангуляр разве не умер?
А
Из опыта, рефреши токенов больше всего бесит тех, кто пилит мобильные прилажки)))
Рассказал им схему как-то. И говорю «мол, access живет 2 часа, и вам придётся рефрешиться» в ответ услышал столько негодования и предложений сделать время жизни хотя бы несколько дней
Рассказал им схему как-то. И говорю «мол, access живет 2 часа, и вам придётся рефрешиться» в ответ услышал столько негодования и предложений сделать время жизни хотя бы несколько дней
AG
А если токен увели. В СПА же ты не можешь токены в куках хранить.
AG
Причем вместе с рефрешем.
AG
Да и разлогинить на всех устройствах можно только через блэк-лист.
MA
А если токен увели. В СПА же ты не можешь токены в куках хранить.
Рефреш одноразовый, при входе реального пользователя с логином и паролем, рефреш злоумышленника станет не действительным. По крайней мере мы такую схему применяем. И Auth0 вроде тоже.
А
А если токен увели. В СПА же ты не можешь токены в куках хранить.
Короче. У меня такая схема реализована.
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
AG
Рефреш одноразовый, при входе реального пользователя с логином и паролем, рефреш злоумышленника станет не действительным. По крайней мере мы такую схему применяем. И Auth0 вроде тоже.
Тогда пользователь может быть залогинен только на одно устройстве?
AG
Короче. У меня такая схема реализована.
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
Токены в бд?
MA
Короче. У меня такая схема реализована.
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
Если один и тот же рефреш юзается повторно(это возможно если токены увели) то все jwt токены становятся невалидными для этого юзера
А как можно сделать невалидными все access токены для пользователя?
А
И рефреши тоже) короче юзеру придётся проходить процедуру авторизации)
MA
Тогда пользователь может быть залогинен только на одно устройстве?
У нас - да, но это бизнес-требование. А так - можно и несколько, тогда блокируется только украденный токен. Но схем много разных, зависит от требований.
А
Токены в бд?
Нет. Но в бд хранится таймштамп. Который обновляется с случае, когда необходимо прекратить все сессии юзера.
AG
Ну, вот я нормальной схемы без хранения токенов в бд не нашел. А головная боль в том, что у нас все на микросеовисах на разных доменах. И авторизация - головная боль.
А
Но это чревато тем, что нужен запрос к бд, для проверки авторизации. Пока ок, а потом можно будет редис знать для этого
MA
Мы храним рефреши в БД, а access - чисто stateless jwt.