OAUTH2 Обновить токен

Question

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

Я смущен, если кто-то украл из печенья маркера доступа, он может также украл обновление маркера и может использовать маркер обновления, чтобы создать новый маркер доступа, как я АЯКС запрос в JQuery (Client Side)

ПРИМЕЧАНИЯ : Я создал запрос ajax для отправки токена обновления на стороне сервера. Я добавляю идентификатор клиента и секретный там с токеном обновления типа типа.

Я сохранил как маркер доступа и обновления маркера в печенье и используйте следующий запрос 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.'); 
          } 
         }, 
       });  
      } 
     } 


}); 

Как я использовал маркер обновления для повышения безопасности?

Answer 1

Здесь в этом блоге с заголовком Refresh Tokens: When to Use Them and How They Interact with JWTs тема с вашего вопроса хорошо обсуждается.

Цитата из этого поста:

Обновить лексемы, как правило, в соответствии со строгими требованиями к хранению, чтобы гарантировать, что они не просочились.

В RFC6819 spec они пишут следующее о хранении токенов на клиенте:

5.1.6. Маркеры доступа

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

• Держите их в транзиторной памяти (доступны только приложения клиента ).
• Проденьте маркеры безопасным использованием безопасного транспорта (TLS).
• Убедитесь, что клиентские приложения не делят токены с третьими сторонами .

И о выдаче токенов обновления:

5.2.2.1. Ограниченная выдача токенов обновления

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

Это означает, что вам следует, вероятно, тщательно подумать о том, где вы хотите хранить токены обновления.Это сообщение Where to Store your JWTs – Cookies vs HTML5 Web Storage касается именно этой темы.

Как уже упоминалось, in this answer on StackOverflow только refresh_token недостаточно, чтобы получить новый access_token.

Обновить токены, если они скомпрометированы, бесполезны, потому что злоумышленник требует идентификатор клиента и секрет в дополнение к токере обновления, чтобы получить токен доступа.

Это также может быть найден в том же RFC6819 spec:

5.2.2.2. Связывание токена обновления с «client_id»

Сервер авторизации должен сопоставлять каждый токен обновления с идентификатором клиента, которому он был выпущен. Сервер авторизации должен проверить, что тот же самый «client_id» присутствует для каждого запроса на обновление токена доступа. Если это возможно (например, конфиденциальные клиенты ), сервер авторизации должен аутентифицировать соответствующий клиент.

Это противодействие обновлению кражи токена или утечки.

Обновить токены следует использовать только один раз. Когда используется refresh_token, он вернет новый access_token и новый refresh_token. Это делает старый refresh_token бесполезным смыслом, который он больше не может использовать.

Он также позволяет серверу аутентификации распознавать, что refresh_token был скомпрометирован, поскольку его следует использовать только один раз. Если новый запрос на обновление с тем же refresh_token на сервере аутентификации знает, что происходит что-то подозрительное. Не уверен, что это правильный путь для сервера, чтобы иметь дело с таким сценарием, хотя ... (может быть, кто-то может пролить свет на это)

Это также в RFC6819 spec:

5,2 .2.3. Обновление маркера вращение

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

OAuth спецификация поддерживает эту меру в том, что ответ лексемы позволяет серверу авторизации вернуть новый маркер обновления даже для запросов с типом гранта «refresh_token».

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

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

В целом хорошо понять протокол OAuth2, чтобы вы могли его правильно реализовать. О безопасности я бы сказал коротко:

• первого спросом для использования JWTs является правильно настроить HTTPS соединения между клиентом и сервером, так что все маркеры правильно шифруется, когда они отправляются туда и обратно ,
• A Второе требование заключается в том, что вы храните маркеры безопасным способом на своем клиенте.

---

Я надеюсь, что это дает вам некоторое представление по этой теме. Если кто-то хочет добавить или исправить мой пост, не стесняйтесь редактировать/обновлять/дополнять ответ или оставлять комментарий.