Access and Refresh, но не могу найти примера куда засовывают именно два токена, есть примеры только по http.SetCookie и туда кладут Access токен. Куда тогда Refresh правильнее положить? Поидее не хорошо будет если токен в токен положу))) или заполню други поля куки помимо value
Верни просто в body объект json с полями HTTP/1.1 200 OK Content-Type: application/json Cache-Control: no-store Pragma: no-cache { "access_token": "SlAV32hkKG", "token_type": "Bearer", "refresh_token": "8xLOxBtZp8", "expires_in": 3600 }
Проблема клиента где он будет их хранить Главное что бы refresh токен был одноразовым
У refresh token тоже expire есть
зачем нужен рефреш если он одноразовый?
И в куку (httponly secure), и в респонсе. Кука - для браузера. В респонсе - для мобильных приложений
При запросе по рефреш токену придет новая пара с новым рефреш токеном
Для ротации токенов
когда делаешь refresh токенов, выдается новый access и новый refresh
Для браузера и мобилки не нужен рефреш токен! Он нужен когда есть third party приложение (сервисная часть), которое зарегистрировано в нашем и ему есть доверие, и которое будет обновлять аксес токен без участия пользователя. Для браузера и мобилки пойдет просто токен/кука/айди сессии, которые могут обновляться при последующих запросах.
не нужно
Ну не делайте тогда
Я просто локал сторажд пихаю
так и есть, нет не блочатся, если нужно принудительно кого-то разлогинить, то можно вести blocklist отозванных токенов (которые еще валидны)
Просто часто вижу когда жаваскриптеры дергают каждый раз рефреш , и получают ацесс на каждый запрос )) видимо им лениво делать обработку expire ?
Можно валидировать публичным ключом разве нет ? Эппл так делает
Генератор на приватном ключе , валидатор на публичном , как в пример ssh ключи
Потому можно в приложения добавлять публичные ключи , и проверять валидность токена не ходя на сервис авторизации.
Обсуждают сегодня