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

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

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

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

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

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

2. Поскольку токены могут иметь несколько областей действия с доступом к нескольким различным службам API, наличие недолговечных токенов доступа не позволяет разработчику службы API получить пожизненный доступ к данным пользователя в службе API B. Компартментализация хороша для безопасности.

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

На мой взгляд, использование токенов обновления дает три основных преимущества:

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

2. Отмена доступа от аутентифицированных пользователей: как только пользователь получит долгоживущий токен доступа, он сможет получить доступ к ресурсам сервера до тех пор, пока его токен доступа не истечет, стандартного способа отозвать токены доступа не существует, если сервер авторизации не реализует настраиваемую логику. что заставляет вас хранить сгенерированный токен доступа в базе данных и выполнять проверки базы данных с каждым запросом. Но с помощью токенов обновления системный администратор может отозвать доступ, просто удалив идентификатор токена обновления из базы данных, поэтому, как только система запросит новый токен доступа с использованием удаленного токена обновления, сервер авторизации отклонит этот запрос, потому что токен обновления больше не доступен. (мы поговорим об этом более подробно).

3. Нет необходимости хранить или запрашивать имя пользователя и пароль: использование токенов обновления позволяет вам запрашивать у пользователя его имя пользователя и пароль только один раз, когда он аутентифицируется в первый раз, тогда сервер авторизации может выдать очень долгоживущий токен обновления (1 год для пример), и пользователь останется в системе все это время, если системный администратор не попытается отозвать токен обновления. Вы можете думать об этом как о способе автономного доступа к ресурсам сервера, это может быть полезно, если вы создаете API, который будет использоваться клиентским приложением, где невозможно продолжать часто запрашивать имя пользователя / пароль.

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

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

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

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

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

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

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

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

Компромисс с недолговечными токенами

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

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

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