какой смысл обновить токен?

я должен признаться, что у меня был этот вопрос в течение очень долгого времени, никогда не понимал.

сказать, что токен аутентификации похож на ключ к безопасному, когда он истекает, он больше не используется. теперь нам дается токен обновления, который можно использовать для получения другого полезного ключа, а другой - до истечения срока действия волшебного ключа. так почему бы просто не установить истечение токена аутентификации как то же, что и токен обновления? зачем вообще беспокоиться?

какова действительная причина этого, может быть, историческая? действительно хочу знать. благодаря

Ответ 1

Ответ, на который ссылается (через @Anders), полезен, в нем говорится:

В случае компромисса, временное окно, для которого оно действует, ограничено, но токены используются через SSL, поэтому вряд ли они будут скомпрометированы.

Я думаю, что важная часть заключается в том, что токены доступа часто регистрируются (особенно когда они используются в качестве параметра запроса, что полезно для JSONP), поэтому лучше всего, чтобы они были кратковременными.

Существует несколько дополнительных причин: широкомасштабные реализации OAuth 2.0 поставщиками услуг:

Серверы API могут безопасно проверять токены доступа без поиска БД или вызовов RPC, если не стоит беспокоиться об отзыве. Это может иметь сильные преимущества в производительности и уменьшить сложность для серверов API. Лучше всего, если вы в порядке с отменой токена, занимающим 30 м-60 м (или любой другой длины маркера доступа). Конечно, серверы API могли также сохранить список токенов в памяти, отозванных за последний час.
Поскольку маркеры могут иметь несколько областей с доступом к нескольким различным службам API, наличие кратковременных токенов доступа препятствует разработчику службы API для получения пожизненного доступа к пользовательским данным в API-сервисе B. Разделение выгодно для безопасности.

Ответ 2

Я читал статью на днях Тайсером Жуде, и я считаю, что это очень полезно, он сказал:

По моему мнению, есть три основных преимущества использования токенов обновления, которыми они являются:

Обновление содержимого токена доступа: поскольку вы знаете, что токены доступа являются самоназванными токенами, они содержат все претензии (информацию) об аутентифицированном пользователе после их создания, теперь, если мы выдаем долгоживущий токен (например, 1 месяц) для пользователя названный "Alex" и зарегистрировавший его в роли "Пользователи", тогда эта информация содержится в токене, который генерировал сервер авторизации. Если вы решили позже (через 2 дня после того, как он получил токен), чтобы добавить его в роль "Админ", тогда нет возможности обновить эту информацию, содержащуюся в генерируемом токене, вам нужно попросить его снова подтвердить подлинность поэтому сервер авторизации добавляет эту информацию в этот вновь созданный токен доступа, и это не представляется возможным в большинстве случаев. Возможно, вы не сможете связаться с пользователями, которые получили долгожданные токены доступа. Поэтому, чтобы преодолеть эту проблему, нам нужно выпустить краткосрочные токены доступа (например, 30 минут) и использовать токен обновления для получения нового токена доступа, как только вы получите новый токен доступа, сервер авторизации сможет добавлять новые требования для пользователя "Alex", который назначает его роли "Admin" после генерирования нового токена доступа
Отмена доступа от пользователей, прошедших проверку подлинности: после того, как пользователь получит долгоживущий адлер доступа, сможет получить доступ к ресурсам сервера, пока его токен доступа не истек, нет стандартного способа аннулирования токенов доступа, если сервер авторизации не выполняет пользовательскую логику, которая заставляет вы должны хранить сгенерированный токен доступа в базе данных и выполнять проверку базы данных с каждым запросом. Но с обновлением токенов системный администратор может отменить доступ, просто удалив идентификатор токена обновления из базы данных, поэтому, как только система запросит новый токен доступа с помощью удаленного токена обновления, сервер авторизации отклонит этот запрос, потому что токен обновления больше не доступен (хорошо входите в это с более подробной информацией).
Нет необходимости хранить или запрашивать имя пользователя и пароль: использование токенов обновления позволяет вам запрашивать у пользователя свое имя пользователя и пароль только один раз после его аутентификации в первый раз, тогда сервер авторизации может выдать очень долгоживущий токен обновления (1 год для пример), и пользователь останется включенным во весь этот период, если системный администратор не попытается отозвать токен обновления. Вы можете думать об этом как о способе автономного доступа к ресурсам сервера, это может быть полезно, если вы создаете API, который будет потребляться приложением переднего конца, когда не представляется возможным часто запрашивать имя пользователя и пароль.

Ответ 3

Я хотел бы добавить к этому еще одну перспективу.

Аутентификация без аутентификации без попадания в БД по каждому запросу

Предположим, вы хотите создать механизм безопасности без состояния (без сеанса), который может выполнять аутентификацию миллионов пользователей, без необходимости делать вызов базы данных для проверки подлинности. Со всем трафиком, которое получает ваше приложение, сохранение вызова БД по каждому запросу стоит много! И он должен быть без гражданства, поэтому его можно легко сгруппировать и увеличить до сотен или даже тысяч серверов.

С помощью старомодных сеансов пользователь входит в систему, и в этот момент мы считываем информацию о пользователе из базы данных. Чтобы избежать необходимости читать его снова и снова, мы храним его в сеансе (обычно в памяти или в кластерном кеше). Мы отправляем идентификатор сеанса клиенту в файл cookie, который привязан ко всем последующим запросам. В последующих запросах мы используем идентификатор сеанса для поиска сеанса, который, в свою очередь, содержит информацию о пользователе.

Поместите информацию о пользователе прямо в токен доступа

Но мы не хотим сессий. Поэтому вместо того, чтобы хранить информацию о пользователе в сеансе, давайте просто поместим его в токен доступа. Мы подписываем токен, чтобы никто не мог вмешиваться в него и престо. Мы можем аутентифицировать запросы без сеанса и без необходимости искать информацию о пользователе из БД для каждого запроса.

Нет сеанса... нет возможности запретить пользователей?

Но отсутствие сеанса имеет большой недостаток. Что делать, если этот пользователь запрещен, например? В старом сценарии мы просто удаляем его сеанс. Затем он должен снова войти в систему, чего он не сможет сделать. Запрет завершен. Но в новом сценарии сеанса нет. Так как мы можем его запретить? Мы должны попросить его (очень вежливо) удалить его токен доступа. Проверить каждый входящий запрос на список запретов? Да, будет работать, но теперь мы снова должны сделать этот вызов БД, которого мы не хотим.

Компромисс с короткими токенами

Если мы считаем приемлемым, что пользователь может по-прежнему использовать свою учетную запись, скажем, через 10 минут после того, как был запрещен, мы можем создать ситуацию, которая представляет собой компромисс между проверкой каждого запроса и только при входе в систему. И это, когда появляются токены обновления. Они позволяют нам использовать механизм без гражданства с кратковременными токенами доступа. Мы не можем отменить эти жетоны, поскольку для них не выполняется проверка базы данных. Мы проверяем дату их истечения по текущему времени. Но как только они истекают, пользователь должен будет предоставить токен обновления, чтобы получить новый токен доступа. На этом этапе мы проверяем БД и видим, что пользователь был заблокирован. Поэтому мы отклоняем запрос на токен доступа, и запрет вступает в силу.

Ответ 4

Короткий возможный ответ:

Обновить токены позволяют использовать время/время разложения токенов. Фактические токены ресурсов недолговечны, а токен обновления может оставаться в силе в течение многих лет (мобильные приложения). Это достигается с лучшей защитой (токены ресурсов не должны быть защищены) и производительность (только API-ток обновления refresh должен проверять правильность работы с БД).