Правильно ли я понимаю, как работает refresh token?
Я как-то давно реализовывал OAuth 2.0 в проекте на бэке, выглядело примерно так:
1) Фронт стучится в эндпоинт авторизации
2) Отдаем access_token, refresh_token, scope, expire_at
3) Пользуется этими токенами для того чтобы стучаться в существующие эндпоинты
И всё, моя задача была выполнена. Сейчас уже мне надо будет стучаться с мобильного приложения в моё апи, которое будет отдавать аксес токен, который будет жить 1 час, и вот я не совсем понимаю как это работает:
Пользователь ходит по моему приложению (понятное дело, по разным эндпоинтам, к которым можно достучаться только с аксес токеном), проходит 1 час, делается запрос, отдается 400 Bad Request (токен не активен), и сразу же в это время делается запрос рефреш токеном, чтобы сгенерировать новую пару? То есть, делается 1 запрос - он не проходит ибо токен устарел, а 2 запрос уже возвращает новую пару, и 3 запрос делается с только что сгенерированным access token?
Не совсем понимаю, что происходит, когда проходит 1 час, и пользователь делает запрос со старым токеном?
По истечению часа, на запрос со старым access token будут приходить отлупы в виде "access token is expired", на клиентах обычно ловят этот ответ и шлют запрос с refresh token, чтобы получить новую пару и сразу же отправляют повторный запрос на тот же endpoint с уже новым access token. Поэтому для пользователя приложения это может происходить незаметно.
но тем не менее, в консоли разработчика (вкладка Network) будут видны ошибки, что аксес токен не активен? после которого следом будет отправлен запрос на перегенерацию токена
То есть, я понимаю это так. Обращаемся к эндпоинту /settings, отдается Bad Request из за того что токен устарел (действие 1) Автоматически делается запрос по новой на рефреш старого токена на новый (действие 2), и уже сейчас мы обращаемся к settings с новым токеном (действие 3)
Т.е. это норма, 3 действия вместо одного?
Twitt, да, это норма.
Это происходит не часто.
Допустим вы открываете мобильное приложение, оно стучится с access token'ом, он проэкспайрился, получаем новую пару и далее пользователь может пользоваться приложением в течении часа без повторного получения рефреша токенов. Обычно делают еще короче время жизни, например 15 минут.
Twitt, смысл короткоживущих access token в том, что если его утащат, то злоумышленник будет иметь очень мало времени, чтобы натворить что-то плохое, перед тем как токен проэкспайрится. Если утащит и refresh token (и будет по нему обновлять себе access token), то обычно когда обновляются токены с помощью refresh token, старые refresh token'ы становятся невалидными. А значит у реального пользователя (не злоумышленника), зарефрешить свой токен не получится (так как злоумышленник им воспользовался уже и старый стал невалидным), а значит реального пользователя перебросит на форму ввода логина и пароля. И тогда, когда он введет свои credentials, ему (реальному пользователю) выдадутся access token и refresh token, а старый refresh token (который перехватил злоумышленник, станет невалидным) и злоумышленник потеряет доступ.
Тут встает вопрос как сделать, чтобы можно было с нескольких устройств пользоваться сервисом так, чтоб не заставлять каждый раз вводить логин пароль (ведь новый refresh token инвалидирует старые), тут на помощь приходит device id, можно инвалидировать старые refresh token'ы, которые были выданы именно этому device id.
