LINUX.ORG.RU

Refresh Token

 


0

1

Многие сайты вместо традиционного механизма сессий на основе cookies используют токены. Современным стандартом является JWT. Строка токена состоит из трех частей: заголовка, тела и сигнатуры. Заголовок и тело представляют соборой сериализованные JSON-данные в кодировке bas64.

При использовании JWT часто выдается два токена. Пример создания access_token:

now = datetime.utcnow()
payload = {
  'exp': now + timedelta(minutes=15),
  'iat': now,
  'uid': user.id,
  'ip': request.remote_addr
}
access_token = jwt.encode(payload, secret_key).decode()

В принципе можно сделать время жизни токена по-больше около 7-14 дней. Кража токена ничего не даст, потому что он привязан к ip.

Каков механизм создания refresh_token:

  1. Он создается так же как и access_token только время его хранения больше?
  2. Должен ли он храниться на сервере?
  3. При использовании refresh_token вместе с ним должен передаваться access_token? Старый access_token после обновления попадает в blacklist?

Пока только такие идеи:

def create_refresh_token(user):
  ret = get_random_chars(length=31)  # можно хеш от чего-нибудь посчитать
  # insert into refesh_tokens values(<refresh_token>, <user.id>, <expiration_date>);
  return ret


@app.route('/auth', methods=['POST'])
def authenticate():
   username = request.json.get('username')
   ...
   ret = {
     'access_token': create_access_token(user),
     'refresh_token': create_refresh_token(user),
   }
   return jsonify(ret)


@app.route('/refresh', methods=['GET'])
def refresh_token():
  # Берем refresh token из заголовка Authentication: Bearer <refresh>
  # select user_id from refresh_tokens where refresh_token = ? and expiration_date > now()
  # из этого user_id создаем новый access_token
★★

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

Какая же бездарная, птушная макака это писала.

anonymous
()
Ответ на: комментарий от static_lab

я вчера ночью писал свои думы. понял что бред написал. можно просто два jwt токена выдавать, только access token как-то помечать (доп. поле "access": true) чтобы refresh token’ом нельзя было доступ к методам api получать

tz4678 ★★
() автор топика
Ответ на: комментарий от tz4678

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

tz4678 ★★
() автор топика

Каков механизм создания refresh_token

Что это такое и зачем оно тебе надо? Всегда просто создают один токен и он работает пока exp не истечет. Когда истек, то отправляют назад логиниться.

Должен ли он храниться на сервере?

Ничего не должно нигде храниться. Суть jwt в stateless автентификации. Он выдается приватным ключем, который хранится на сервере логинов, а верифицируется чем попало, допустим nginx с публичным ключем.

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

Недостатком jwt является сложность логаута одного пользователя. Тут или добавлять еще одно поле с каким-то идентификатором кокретного токена и добавлять в блеклист. Или на каждого пользователя держать отдельный private/public key. И то и то - приседания.

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

согласно спецификации там есть jti (JSON Web Token Identifier) он как раз может где-то храниться в базе

tz4678 ★★
() автор топика
Ответ на: комментарий от tz4678

Т.е. токен выдаем на неограниченный период, в нем храним только jti. jti - это uuid в таблице access_tokens (id, user_id). Если у пользователя воруют токен, то он авторизуется по новой и нажимает на кнопку «logout from all devices», которая удаляет id всех токенов, выданных для этого пользователя

tz4678 ★★
() автор топика
Ответ на: комментарий от tz4678

sub - это уникальный идентефикатор пользователя, например, LDAP-овский «i.ivanov». а то что я выше описал так кто-нибудь делает?

tz4678 ★★
() автор топика
Ответ на: комментарий от tz4678

Если у пользователя воруют токен, то он авторизуется по новой и нажимает на кнопку «logout from all devices», которая удаляет id всех токенов, выданных для этого пользователя

Каким образом ты это узнаешь?

anonymous
()
Ответ на: комментарий от tz4678

Упомянутые тобою говнотокены - это просто формат данных с подписью. Ты можешь использовать что угодно. Желательно ещё и шифровать те данные, которые не должны быть публичными(никогда).

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

Как лучше сделать - лучше сделать блеклист. Если у тебя токены будут жить лишь определённое время, то хранить этот блеклист нужно только за последние N минут/часов.

Рассуждения про «увели токен» вообще несостоятельны. Если увели - твоему пользователю конец. Ты об этом никогда не узнаешь.

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

anonymous
()
Ответ на: комментарий от anonymous

Токены - это устаревающий расходник, который никому не интересен.

Тут правила криптографии не работают

Ничего не понял. Все на токенах сейчас работает без проблем

vertexua ★★★★★
()
Ответ на: комментарий от vertexua

Ничего не понял. Все на токенах сейчас работает без проблем

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

Давай попроще. Есть у нас есть ключ, которым мы шифруем соединения. Если мы просрём какой-то старый ключ - мы просрём все данные, которые им были зашифрованы.

Если же мы просрём старый токен - нам насрать. Он уже превратился в тыкву. И ты можешь его превратить в тыкву.

anonymous
()

Зачем токен привязывать к айпи? Человек может переключаться с одной мобильной сети на другую а токен должен работать

Jaberwock ★★★
()

В принципе можно сделать время жизни токена по-больше около 7-14 дней. Кража токена ничего не даст, потому что он привязан к ip.

Тогда использование рефреш токена ничего не даст.

Он нужен для того, что ограничить время, которое злоумышленник может пользоваться украденным access токеном. А access-токен делают короткоживущим.

Более того, в доках oauth вообще указано, что браузерное приложение не должно иметь доступ (!!) к refresh token. То есть refresh токен - это вообще не для сайтов!!!

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

Старый access_token после обновления попадает в blacklist?

В blacklist попадают и access и refresh токены, иначе в этом нет смысла. Refresh токен используется без access токена, так как время жизни access токена к этому моменту прошло.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.