Блог

Я только изучаю JWT в nodejs, и я узнал о токенах обновления.

Насколько я понимаю, пользователь получает токен доступа и токен обновления. По истечении срока действия токена доступа выполняется запрос, содержащий токен обновления, для получения нового токена доступа. Чтобы получить новый токен доступа, сервер проверяет, содержится ли полученный токен обновления в базе данных. Если токен обновления украден, его можно легко удалить из базы данных и предотвратить дальнейшие обновления.

Мой вопрос: почему бы нам просто не заставить токены доступа вести себя как токены обновления? т.е. мы храним их в базе данных и проверяем, присутствуют ли они там при выполнении запроса, а при компрометации просто удаляем их?

Ключевым элементом для ответа на ваш вопрос является: вам нужно добавить дату истечения срока действия токенов доступа, которые вы предоставляете клиентам. Это основная цель использования токена обновления.

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

С токенами обновления и истекающими access_tokens, вы знаете, что окно уязвимости действительно мало.

Теперь ваш второй вопрос: почему мы не можем заставить access_tokens вести себя как refresh_tokens?

Ключевая идея здесь заключается в том, чтобы хранить ваш refresh_token в безопасном месте и предоставлять доступ только к токенам access_tokens.

И, кстати, у refresh_tokens есть одна задача: передавать информацию для создания новых access_tokens, у access_tokens, с другой стороны, есть своя работа: передавать информацию, необходимую для предоставления вам прямого доступа к ресурсам.

Если вы обратите внимание на большинство серьезных веб-сайтов, у них есть централизованный сервер аутентификации, который обслуживает access_tokens.

Ответы на комментарии:

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

другими словами:

• аутентификация.yourapp.com : хранит access_token_key и refresh_token_key
• api.yourapp.com : сохраняет только access_token_key, чтобы убедиться, что пользователи действительно прошли аутентификацию при вашей авторизации.yourapp.com домен и api.yourapp.com могу легко это подтвердить. если access_token_key был скомпрометирован, срок службы уязвимости сокращается, и вы можете легко изолировать атакованный сервер.

если один из ваших серверов скомпрометирован, остальные безопаснее.