Какая точка обновления токена?

Question

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

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

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

Answer 1

Ссылаженный ответ (через @ @ @ @anders) полезно, он предусматривает:

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

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

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

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

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

Answer 2

Я читал Статья на днях Taiseer Judeh и я считаю очень полезным, он сказал:

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

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

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

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

Answer 3

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

Аутентификация без природы без удара DB на каждый запрос

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

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

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

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

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

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

компромисс с короткоживущими токенами

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

Answer 4

Запасы Возможный ответ:

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