OAUTH2 Обновить токен
Я немного путаю Refresh Token в OAuth2.
Как говорится, токен доступа ограничивает временное окно 1 часом, в течение которого хакер может использовать учетные данные пользователя, а токен обновления является токеном с длительным сроком действия, который можно использовать для воссоздания токена доступа.
Я запутался, если кто-то украл токен доступа из cookie, он также может украсть токен обновления и может использовать токен обновления для создания нового токена доступа, поскольку у меня есть запрос ajax в JQuery (на стороне клиента)
НОТА: Я создал ajax-запрос для отправки токена обновления на стороне сервера. Я добавляю идентификатор клиента и секретный ключ с токеном обновления типа предоставления.
Я сохранил и токен доступа, и токен обновления в cookie и использую следующий запрос ajax для получения нового токена доступа
jQuery(document).ajaxError(function(event, jqXHR, ajaxSettings, thrownError) {
//console.log('event');console.log(event);
//console.log('jqXHR');console.log(jqXHR);
//console.log('ajaxSettings');console.log(ajaxSettings);
//console.log('thrownError');console.log(thrownError);
if(jqXHR.status == 403)
{
console.log('User is not Loged in Redictet to Login Page');
}
if(jqXHR.status == 401)
{
var refresh_token = Cookies.get('refresh_token');
if(refresh_token != undefined)
{
$.ajax({
url: CONNECT_API_URL+'/refresh-token',
type: "POST",
data:{ refresh_token: refresh_token },
success: function(response, status, jqXHR){
if(response.access_token != undefined)
{
var expires_in = new Date(new Date().getTime() + response.expires_in * 1000);
var access_token = response.token_type+' '+response.access_token;
Cookies.set('access_token', access_token, { expires: expires_in });
Cookies.set('refresh_token', response.refresh_token, { expires: 14 });
$.ajax(ajaxSettings); // Re send same ajax request with access token in cookie has been set
}
else
{
console.log('Redirect to login page.');
}
},
});
}
}});
Как использовать токен обновления для повышения безопасности?
Решение
Здесь на этом блоге с заголовком Обновить токены: когда их использовать и как они взаимодействуют с JWT тема из вашего вопроса хорошо обсуждается.
Цитата из этого поста:
Для маркеров обновления обычно применяются строгие требования к хранению, чтобы они не были утечки.
в RFC6819 спецификация они пишут следующее о хранении токенов доступа на клиенте:
5.1.6. Жетоны доступа
Следующие меры должны использоваться для защиты токенов доступа:
- Храните их во временной памяти (доступной клиенту
только приложение).- Безопасно передавайте токены, используя безопасный транспорт (TLS).
- Убедитесь, что клиентские приложения не делят токены с третьим
стороны.
А по поводу выдачи токенов обновления:
5.2.2.1. Ограниченная выдача токенов обновления
Сервер авторизации может принять решение, основываясь на соответствующей политике,
не выдавать токены обновления. Поскольку токены обновления являются долгосрочными
Учетные данные, они могут быть подвергнуты краже. Например, если
сервер авторизации не доверяет клиенту безопасно хранить такие
токены, он может отказаться выдавать клиенту токен обновления.
Это означает, что вы, вероятно, должны тщательно продумать, где вы хотите хранить свои токены обновления. Эта почта Где хранить ваши JWT — Cookies против HTML5 Web Storage занимается именно этой темой.
Как также упоминалось в этом ответе на StackOverflow только refresh_token недостаточно, чтобы получить новый access_token,
Токены обновления, если они скомпрометированы, бесполезны, поскольку злоумышленнику требуется идентификатор клиента и секрет в дополнение к токену обновления, чтобы получить токен доступа.
Это также можно найти в том же RFC6819 спецификация:
5.2.2.2. Привязка токена обновления к «client_id»
Сервер авторизации должен сопоставлять каждый токен обновления с
идентификатор клиента, которому он был выдан. Авторизация
Сервер должен проверить, что один и тот же «client_id» присутствует для каждого
запрос на обновление токена доступа. Если возможно (например, конфиденциально
клиенты), сервер авторизации должен аутентифицировать соответствующие
клиент.Это контрмера против обновления кражи токена или утечки.
Жетоны обновления следует использовать только один раз. Когда refresh_token используется, он вернет новый access_token и новый refresh_token, Это делает старый refresh_token бесполезный смысл, он больше не может быть использован.
Это также позволяет серверу аутентификации распознавать, что refresh_token был скомпрометирован, поскольку его следует использовать только один раз. Если новый запрос на обновление с тем же refresh_token приходит на сервер аутентификации, знает, что происходит что-то подозрительное. Не уверен, каким именно образом сервер может справиться с таким сценарием, хотя … (может быть, кто-то еще может пролить свет на это)
Это также в RFC6819 спецификация:
5.2.2.3. Обновить токен вращения
Обновление ротации токенов предназначено для автоматического обнаружения и
предотвратить попытки использовать один и тот же токен обновления параллельно
разные приложения / устройства. Это происходит в случае кражи токена из
клиент и впоследствии используется как злоумышленником, так и
законный клиент. Основная идея состоит в том, чтобы изменить токен обновления
значение с каждым запросом на обновление, чтобы обнаружить попытки
получить токены доступа, используя старые токены обновления. Так как
сервер авторизации не может определить, является ли злоумышленник или
законный клиент пытается получить доступ, в случае такого доступа
попробуйте действительный токен обновления и авторизацию доступа
связанные с этим оба аннулированы.Спецификация OAuth поддерживает эту меру в том, что токен
ответ позволяет серверу авторизации возвращать новое обновление
токен даже для запросов с типом предоставления «refresh_token».Примечание. Эта мера может вызвать проблемы в кластерных средах.
поскольку необходимо использовать действующий токен обновления. В
такая среда, другие меры могут быть более подходящими.
Ваши токены доступа и обновления могут быть скомпрометированы на клиенте, но они также могут быть перехвачены где-то между вашим клиентом и сервером.
refresh_token отправляется только один раз клиенту, в то время как access_token отправляется на сервер с каждым запросом, поэтому шансы того, что человек посередине получит в свои руки access_token гораздо больше, чем вероятность того, что ваш refresh_token скомпрометирован.
В целом, хорошо понимать протокол OAuth2, чтобы вы могли правильно его реализовать. О безопасности я бы сказал вкратце:
- первое требование для использования JWT — это правильно настроенное https-соединение между вашим клиентом и сервером, чтобы все токены были должным образом зашифрованы при отправке туда и обратно.
- второе требование является то, что вы храните токены безопасным способом на вашем клиенте.
Я надеюсь, что это даст вам некоторое представление об этой теме. Если кто-то хочет добавить или исправить мое сообщение, пожалуйста, не стесняйтесь редактировать / обновлять / дополнять ответ или оставлять комментарии.
Другие решения
Других решений пока нет …