Защищено ли использование Refesh Token при аутентификации на основе токенов?

Я создаю аутентификацию на основе токенов (Node.js с использованием паспорта / JWT с клиентом angular).

После того, как пользователь вводит свои учетные данные, он получает токен доступа, который он отправляет в каждом запросе внутри заголовка (заголовок: bearer TOKEN).

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

Я кое-чего не понимаю, возможно, я что-то упускаю:

  1. Как долгоживущие / никогда не истекающие токены обновления не нарушают безопасность короткоживущих токенов доступа.

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

ПРИМЕЧАНИЕ. Мне известно, что токены обновления отправляются при первоначальном входе в систему, поэтому их нельзя подделать при каждом запросе, но если они подделываются при первоначальном запросе, они уязвимы.


jwt security access-token token http-token-authentication
person Aviran Cohen    schedule 08.12.2014    source источник

Ответы (2)


arrow_upward
4
arrow_downward

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

person Hans Z.    schedule 08.12.2014
comment
Думаю, я начинаю понимать. Таким образом, токен доступа передается между клиентом и сервером, а токен обновления передается между сервером и сервером авторизации. но что, если у моего сервера есть и ресурс, и логика авторизации, и он не ретранслируется на другой сервер авторизации? тогда токен обновления будет ненужным, и когда клиенты предоставят устаревший токен доступа или токен доступа, срок действия которого скоро истечет, я просто сгенерирую новый токен и передам его ему? Разве это не означает, что если у хакера есть токен доступа, он может использовать его вечно, просто обновляя его снова и снова? - person Aviran Cohen; 08.12.2014
comment
новый токен доступа должен быть предоставлен клиентам только на основе какого-то разрешения на авторизацию, как это называется в OAuth 2.0, и не должен быть основан только на владении старым токеном доступа, в противном случае время жизни токена не имеет значения. - person Hans Z.; 08.12.2014
comment
Можете ли вы сказать мне, какое разрешение на авторизацию я могу использовать, не требуя от пользователя повторного ввода учетных данных? (чтобы не запрашивать логин каждый раз, когда истекает срок действия токена доступа) - person Aviran Cohen; 08.12.2014
comment
это грант токена обновления ... если хакер получит токен обновления, он должен быть отозван, и пользователю снова будет предложено пройти аутентификацию; две стороны одной медали: либо вы полагаетесь на существующий токен, либо запрашиваете у пользователя аутентификацию; если ваш клиент неуверен, в любом случае нет лекарства - person Hans Z.; 08.12.2014
comment
Привет, Ганц, не могли бы вы помочь мне в этом stackoverflow.com/questions/28759590/ - person Gopinath Shiva; 02.03.2015

arrow_upward
0
arrow_downward

Я использую следующий подход:

Таблицы / указатели:

  1. Таблица пользователей (содержит только идентификаторы пользователей и все связанные с ними метаданные)
  2. Таблица JWT (три поля: user_id, access_token, refresh_token)

Процесс аутентификации

1. Когда ранее не аутентифицированный пользователь входит в систему, выдайте JWT, который содержит токен доступа и токен обновления. Обновите токен обновления в таблице JWT вместе с user_id и токеном доступа.

2.Убедитесь, что срок действия JWT является небольшим / удобным для ваших пользователей. Обычно меньше часа.

4.Когда клиент делает запрос через JWT

а. Проверить срок действия токена доступа. Если срок действия токена не истек - ›продолжайте, не обращаясь к таблицам db.

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

Если да, создайте новый JWT с ответом и обновите новый токен обновления, токен доступа в таблицу JWT.

если нет, вернуть 401. Затем клиент вынужден попросить пользователя войти в систему.

КОНЕЦ.

Обобщить,

1. Вызовы DB требуются только для проверки действительности токена обновления.

2. Эта система позволяет пользователю входить в систему с любого количества устройств с любым количеством JWT.

3. Все JWT, относящиеся к пользователю, могут быть признаны недействительными путем удаления токенов обновления, связанных с этим пользователем, из таблицы JWT, это может быть сделано, например, когда пользователь меняет свой пароль. Это, по сути, сужает окно компрометации до времени истечения срока действия токена доступа / JWT.

Я считаю, что это намерение JWT. Процент вызовов БД на пользователя зависит от времени истечения срока действия, продолжительности пребывания пользователя на вашем веб-сайте и т. Д.

person Algorini    schedule 16.08.2020