Почему у OAuth v2 есть токены доступа и обновления?

Question

Раздел 4.2 проекта протокола OAuth 2.0 указывает, что сервер авторизации может возвращать как access_token (который используется для аутентификации себя с помощью ресурса), а также refresh_token, который используется исключительно для создания нового access_token:

https://tools.ietf.org/html/rfc6749

Почему есть оба? Почему бы просто не сделать access_token длиться до тех пор, пока refresh_token и не иметь refresh_token?

Answer 1

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

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

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

Это, конечно, отличается от реализаций, где вы не контролируете серверы авторизации и ресурсов.

Вот хорошая ветка, рассказывающая об использовании токенов обновления: OAuth Archives.

Цитата из вышесказанного, рассказывающая о целях безопасности токена обновления:

Обновить токены... снижает риск долгой утечки access_token (параметр запроса в файле журнала на небезопасном сервере ресурсов, бета-версия или плохо кодированное приложение сервера ресурсов, клиент JS SDK на не https-сайте, который помещает access_token в печенье и т. д.)

Answer 2

Ссылка на обсуждение, предоставленная Catchdave, содержит еще одно обоснованное замечание Дика Хардта, которое, на мой взгляд, стоит упомянуть здесь в дополнение к тому, что было написано выше:

Мое воспоминание о фишках обновления было для безопасности и аннулирования. <...>

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

Действительно, в ситуации, когда сервер ресурсов и сервер авторизации являются одним и тем же объектом, и когда соединение между пользователем и любым из них (как правило) одинаково безопасно, нет особого смысла хранить токен обновления отдельно от токена доступа.

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

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

Как должна работать система с долгоживущими токенами доступа

Сервер позволяет Клиенту получить доступ к данным Пользователя в рамках заранее определенного набора областей путем выдачи токена. Поскольку мы хотим сохранить токен отзывным, мы должны сохранить в базе данных токен вместе с установленным или снятым флагом "отзывано" (в противном случае, как бы вы это сделали с автономным токеном?) База данных может содержать столько же, сколько len(users) x len(registered clients) x len(scopes combination) записей. Затем каждый запрос API должен попадать в базу данных. Хотя запросы к такой базе данных, выполняющие O(1), довольно тривиальны, сама точка отказа может отрицательно повлиять на масштабируемость и производительность системы.

Как должна работать система с долгоживущим токеном обновления и недолговечным токеном доступа

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

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

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

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

компромиссы

Токены обновления частично устраняют SPoF (единую точку отказа) базы данных токенов доступа, но у них есть некоторые очевидные недостатки.

1. Окно". Промежуток времени между событиями "пользователь аннулирует доступ" и "доступ гарантированно будет аннулирован".

2. Усложнение клиентской логики.

   без обновления токена

   • отправить запрос API с токеном доступа
   • если токен доступа недействителен, не удалось и попросить пользователя повторно пройти аутентификацию

   с токеном обновления

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

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

Answer 3

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

Думайте о сценарии как это. Вы выдаете пользователю токен доступа на 3600 секунд и обновляете токен намного дольше, чем за один день.

1. Пользователь - хороший пользователь, он дома и включает / выключает ваш сайт, совершая покупки и поиск на своем iPhone. Его IP-адрес не меняется и имеет очень низкую нагрузку на ваш сервер. Как 3-5 запросов страниц каждую минуту. Когда его 3600 секунд на токене доступа закончились, ему требуется новый с токеном обновления. Мы на стороне сервера проверяем его историю активности и IP-адрес, думаем, что он человек и ведет себя сам. Мы даем ему новый токен доступа для продолжения использования нашего сервиса. Пользователю не нужно будет снова вводить имя пользователя / пароль до тех пор, пока он не достигнет одного дня жизни маркера обновления.

2. Пользователь - неосторожный пользователь. Он живет в Нью-Йорке, США, закрыл свою вирусную программу и был взломан хакером в Польше. Когда хакер получил токен доступа и обновил токен, он пытается выдать себя за пользователя и использовать наш сервис. Но после истечения срока действия токена доступа с коротким сроком действия, когда хакер пытается обновить токен доступа, мы на сервере заметили резкое изменение IP-адреса в истории поведения пользователя (эй, этот парень входит в систему в США и теперь обновляет доступ в Польше только после 3600-х годов???). Мы прекращаем процесс обновления, лишаем законной силы токен обновления и предлагаем ввести имя пользователя / пароль еще раз.

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

Вы можете видеть, что токен обновления работал отлично, когда мы пытаемся сбалансировать нашу работу, пользовательский опыт и потенциальный риск кражи токена. Ваша сторожевая собака на стороне сервера может проверять больше, чем изменение IP, частоту вызовов API, чтобы определить, является ли пользователь хорошим пользователем или нет.

Еще одно слово: вы также можете попытаться ограничить контроль ущерба от украденного токена / злоупотребления обслуживанием, внедрив для каждого вызова API базовый IP-сторож или другие меры. Но это дорого, так как вы должны читать и записывать записи о пользователе и замедлять реакцию вашего сервера.

Answer 4

Ни один из этих ответов не доходит до основной причины, по которой существуют токены обновления. Очевидно, что вы всегда можете получить новую пару access-token / refresh-token, отправив свои учетные данные клиента на сервер аутентификации - так вы и получите их в первую очередь.

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

Answer 5

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

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

Чтобы получить начальный токен доступа и обновить токен, необходимо:

• Идентификатор пользователя
• Пароль пользователя
• Идентификатор клиента
• Секрет клиента

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

• Идентификатор клиента
• Секрет клиента
• Токен обновления

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

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

Answer 6

Этот ответ был составлен с помощью двух старших разработчиков (Джона Брайтона и Дэвида Дженнеса).

Основная причина использования токена обновления - уменьшить поверхность атаки.

Предположим, что нет ключа обновления, и давайте рассмотрим этот пример:

В здании 80 дверей. Все двери открываются одним ключом. Ключ меняется каждые 30 минут. По истечении 30 минут я должен отдать старый ключ мастеру ключей и получить новый ключ.

Если я хакер и получу ваш ключ, то по истечении 30 минут я перешлю его изготовителю ключей и получу новый ключ. Я смогу постоянно открывать все двери независимо от смены ключа.

Вопрос: Сколько у меня было возможностей взлома ключа за 30 минут? У меня было 80 возможностей взлома каждый раз, когда вы использовали ключ (подумайте об этом как о создании сетевого запроса и передаче токена доступа для идентификации). Итак, это 80-кратная поверхность атаки.

Теперь давайте рассмотрим тот же пример, но на этот раз предположим, что есть ключ обновления.

В здании 80 дверей. Все двери открываются одним ключом. Ключ меняется каждые 30 минут. Чтобы получить новый ключ, я не могу передать старый токен доступа. Я должен передать только ключ обновления.

Если я хакер и получу ваш ключ, я могу использовать его в течение 30 минут, но по истечении 30 минут отправка ключа изготовителю ключей не имеет значения. Если я это сделаю, то создатель ключей просто скажет этот неверный токен обновления. Чтобы иметь возможность распространить свой хак, мне пришлось бы взломать курьера на ключника. У курьера есть отдельный ключ (считайте это токеном обновления).

Вопрос: Сколько у меня было возможностей взлома ключа обновления за 30 минут? 80? Нет. У меня была только одна возможность взлома. В это время курьер общается с ключником. Итак, это поверхность атаки 1X. У меня было 80 возможностей взлома ключа, но через 30 минут они не работают.

---

Сервер будет проверять токен доступа на основе учетных данных и подписания (обычно) JWT.

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

Дело в том, что токен доступа добавляется к каждому запросу, который вы делаете, тогда как токен обновления используется только во время потока обновления, поэтому меньше шансов, что MITM увидит токен

Частота помогает злоумышленнику. Heartbleed-как потенциальных уязвимостей в SSL, потенциальных уязвимостей в клиенте, и потенциальные недостатки безопасности на сервере все делают утечки возможно.

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

Компартментализация хороша для безопасности.

И последнее, но не менее важное: посмотрите этот потрясающий ответ

---

О каком токене обновления НЕ идет речь?

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

Answer 7

Этот ответ от Джастина Ричера через стандартный список рассылки OAuth 2. Это опубликовано с его разрешения.

---

Срок действия токена обновления до сервера авторизации (AS) - он может истечь, быть отозван и т. Д. Разница между токеном обновления и токеном доступа заключается в аудитории: токен обновления возвращается только на сервер авторизации, токен доступа отправляется на сервер ресурсов (RS).

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

OpenID Connect не только предоставляет вам информацию о пользователях из токена доступа, но также дает вам идентификационный токен. Это отдельный фрагмент данных, который направлен на самого клиента, а не на AS или RS. В OIDC вы должны рассматривать кого-то, кто действительно "вошел" по протоколу, только если вы можете получить новый идентификационный токен. Освежить его вряд ли будет достаточно.

Для получения дополнительной информации, пожалуйста, прочитайте http://oauth.net/articles/authentication/

Answer 8

Клиенты могут быть скомпрометированы разными способами. Например, мобильный телефон может быть клонирован. Истечение срока действия маркера доступа означает, что клиент вынужден повторно пройти аутентификацию на сервере авторизации. Во время повторной аутентификации сервер авторизации может проверять другие характеристики (IOW выполняет адаптивное управление доступом).

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

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

Answer 9

Чтобы еще больше упростить ответ B T: используйте маркеры обновления, если вы обычно не хотите, чтобы пользователь снова вводил учетные данные, но при этом хотите, чтобы у вас была возможность отозвать разрешения (путем отзыва маркера обновления)

Вы не можете отозвать токен доступа, только токен обновления.

Answer 10

Почему бы просто не сделать access_token последним до тех пор, пока refresh_token и не иметь refresh_token?

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

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

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

Answer 11

Предположим, вы делаете access_token очень долгим и не имеете refresh_token, поэтому в один прекрасный день хакер получит этот access_token, и он сможет получить доступ ко всем защищенным ресурсам!

Но если у вас есть refresh_token, время доступа access_token короткое, поэтому хакеру сложно взломать ваш access_token, потому что он через некоторое время станет недействительным. Access_token может быть восстановлен только с использованием не только refresh_token, но также client_id и client_secret, которых у хакера нет.

Answer 12

Все дело в масштабировании и сохранении состояния вашего сервера ресурсов.

• Ваш сервер/ресурсный сервер

  • Сервер не имеет состояния, то есть не проверяет какое-либо хранилище, чтобы отвечать очень быстро. Делает это с помощью открытого ключа для проверки подписи токена.

  • Проверяет каждый запрос.

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

  • должен иметь короткий срок действия (несколько минут), так как его нельзя отозвать, в случае утечки урон ограничен.

• Сервер аутентификации/сервер OAuth
  • Сервер не без гражданства, но это нормально, потому что запросов намного меньше.
  • Проверяет только когда access_tokenистек. (например, каждые 2 минуты)
  • Скорость запросов намного ниже, чем у сервера ресурсов.
  • Сохраняет токен обновления в БД и может отозвать его.
  • refresh_tokenможет иметь длительный срок действия (несколько недель/месяцев), в случае утечки есть способ отозвать его.

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

Answer 13

Пока токен обновления сохраняется сервером авторизации. Токен доступа самодостаточен, поэтому сервер ресурсов может проверить его, не сохраняя, что экономит усилия поиска в случае проверки. Еще один момент, отсутствующий в обсуждении, от rfc6749 # page-55

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

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

Answer 14

Токены обновления и токены доступа - это просто терминология.

Эта небольшая аналогия может помочь укрепить обоснование использования токенов доступа и токенов обновления:

Предположим, Алиса отправляет Бобу чек по почте, который может быть обналичен в течение 1 часа (гипотетически) с момента выписки, иначе банк его не оплатит. Но Алиса также включила в сообщение, предназначенное для банка, записку, в которой просила банк принять и обналичить чек на случай, если он немного задержится (в пределах оговоренного диапазона).

Когда Боб получит эту проверку, он сам сбросит эту проверку, если увидит, что это подделано (подделка токена). Если нет, он может отнести его в банк, чтобы обналичить. Здесь, когда банк замечает, что время выдачи превысило 1-часовой лимит времени, но видит подписанную записку от Алисы с просьбой к банку обналичить деньги в случае оговоренной задержки в пределах допустимого диапазона.

Увидев эту записку, банк пытается проверить подписанное сообщение и проверяет, есть ли у Алисы необходимые разрешения. Если да, банк обналичивает чек. Теперь Боб может подтвердить это Алисе.

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

• Алиса (Отправитель - Клиент)
• Боб (Получатель - Сервер ресурсов)
• Банк (Сервер авторизации)
• Процесс проверки (доступ к базе данных)
• Проверить (токен доступа)
• Примечание (обновить токен)

В основном мы хотим уменьшить количество вызовов API к серверу аутентификации и, в конечном итоге, к базе данных, чтобы оптимизировать масштабируемость. И нам нужно делать это с правильным балансом между удобством и безопасностью.

Примечание. Определенно чаще сервер Auth отвечает на запросы раньше, чем сервер ресурсов в цепочке.

Answer 15

Давайте рассмотрим систему, в которой каждый пользователь связан с одной или несколькими ролями, а каждая роль связана с одной или несколькими привилегиями доступа. Эта информация может быть кэширована для лучшей производительности API. Но тогда могут быть изменения в конфигурации пользователя и роли (например, может быть предоставлен новый доступ или текущий доступ может быть отменен), и они должны быть отражены в кеше.

Для этой цели мы можем использовать токены доступа и обновлять их. Когда API вызывается с токеном доступа, сервер ресурсов проверяет кэш на наличие прав доступа. Если есть какие-либо новые права доступа, это не отражается сразу. Когда срок действия маркера доступа истекает (скажем, через 30 минут), и клиент использует токен обновления для создания нового токена доступа, кэш можно обновить, обновив информацию о правах доступа пользователя из БД.

Другими словами, мы можем перемещать дорогостоящие операции из каждого вызова API, используя токены доступа, в событие генерации маркеров доступа, используя токен обновления.

Answer 16

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

Например, 1: не использовать токены обновления; реализовать только долгоживущие токены доступа: у вас должна быть возможность отозвать токены доступа, если пользователь злоупотребляет услугой (например, не платит подписку) => Вам нужно будет проверять действительность токена доступа при каждом вызове API, который требуется токен доступа, и это будет медленным, потому что для этого нужен поиск в БД (может помочь кеширование, но это более сложно).

Например, 2: Внедрить токены обновления и краткосрочные токены доступа: у вас должна быть возможность отозвать токены доступа, если пользователь злоупотребляет услугой (например, не оплачивает подписку) => Срок действия краткосрочных токенов доступа истечет после короткого белый (например, 1 час), и пользователю потребуется получить новый токен доступа, поэтому нам не нужна проверка при каждом вызове API, для которого требуется токен доступа. Вам просто нужно проверить пользователя при создании токена доступа из токена обновления. Для плохого пользователя вы можете выйти из системы, если маркер доступа не может быть сгенерирован. Когда пользователь пытается снова войти в систему, проверка будет запущена снова и вернет ошибку.

Answer 17

У меня есть несколько дополнительных ресурсов, которые разъясняют некоторые вещи о том, зачем нам нужен refresh_token. Некоторые из ключевых моментов этих ресурсов следующие:

• В реальном мире лучше иметь отдельные серверы с именеми
  • authServer — используется только для аутентификации и авторизации. Этот сервер отвечает за выдачу,а также&пользователи
  • resourceServer — этот сервер (также может быть несколько серверов с балансировкой нагрузки) предоставляет защищенные данные. Эти данные могут быть как,и так далее в e-commerce-проекте например
• Одно из применений заключается в том, что нам не нужно отправлятьпо сети (от front-end до authServer ) каждый раз, когда нам нужен новый файл . Это следует делать только в первый раз (когда у вас его еще нет), и теперь вы получите новое от authServer , чтобы вы могли продолжать делать запросы к вашему защищенному resourceServer . Это преимущество заключается в том, что пользователям не нужно каждый раз вводить учетные данные, из-за чего имя пользователя и пароль пользователя не могут быть легко скомпрометированы.
• Другое основное использование заключается в том, что, скажем, ваш authServer очень защищен по сравнению с resourceServer в реальном мире (сторонние службы, такие как auth0 , okta , azure и т. д., или ваша собственная реализация). Вы будете отправлять только на resourceServer (для получения данных), и вам никогда не придется отправлять на resourceServer . Таким образом, есть большая вероятность, что при отправке на resourceServer хакер перехватит ваш resourceServer (поскольку он не так безопасен, как authServer), который получит доступ к вашему недолговечному .
  • По этой причине у него короткий срок службы (около 30 минут). Помните, что когда это истечет, вы отправите на authServer (который более безопасен, чем resourceServer ), чтобы получить новый файл . Поскольку вы никогда не отправляете файл resourceServer , хакер, перехватывающий ресурсServer, не сможет получить ваш файл . Если вы, как разработчик, по-прежнему сомневаетесь, что ваши пользователи также могут быть взломаны, вы можете выйти из системы всех пользователей (сделать недействительными для всех пользователей), и таким образом пользователи снова войдут в систему (указав имя пользователя и пароль), чтобы получить новый+и дело снова пойдет на поправку.

Некоторые полезные ресурсы

Рабочий процесс с токеном обновления и без него — Youtube

Пример кода аутентификации JWT — Node JS — Youtube

Answer 18

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

• Revokable Tokens - токены, которые необходимо проверить на сервере авторизации
  • может быть объединен в цепочку (см. RTR — ротация токенов обновления)
  • можно использовать для создания NonRevokable Tokens, но можно и напрямую (когда объемы небольшие и чек не становится обузой)
  • может быть долгоживущим, но это зависит от того, как часто пользователю нужно беспокоиться об учетных данных (имя пользователя/пароль), чтобы получить новый
  • может быть признан недействительным на RTR или любом другом подозрительном поведении
• NonRevokable Tokens — самодостаточные токены, которые не нужно проверять на сервере авторизации.
  • полезны для больших данных, распределенных серверов/вызовов API для горизонтального масштабирования
  • должны быть недолговечными (поскольку не подлежат отзыву)

---

В 2020 году стало общепринятым, что токен обновления также может существовать в браузере (изначально предлагался для серверных систем) — см . https://pragmaticwebsecurity.com/articles/oauthoidc/refresh-token-protection-implications. Из-за этого акцент был переключен с «обновляемости» (как серверная часть в отсутствие пользователя продлит доступ к API) на «отзываемость».

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

В качестве примечания о передовой практике в 2021 году система всегда может начинать с отзывных токенов и переходить на неотзывные, когда нагрузка на сервер авторизации возрастает.

Answer 19

Меня не устраивает ни один из ответов с высоким рейтингом, поэтому я добавлю свой.

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

Но у вас есть отдельный (долговечный) токен, который вы отправляете никому, кроме единственной службы, которой вы уже доверяете - той же службы, которая выдала вам ваш токен доступа для начала (скажем, Google или что-то еще, что вы использовали для входа в StackOverflow). . И вы используете этот токен для получения новых недолговечных токенов, которые затем снова передаются третьим лицам, которым вы меньше доверяете.

Все это означает, что если ваше собственное устройство или приложение или вы сами подверглись риску, токен обновления вообще бесполезен (как это обычно верно и для любого другого механизма аутентификации). Но если скомпрометирован StackOverflow, будет доступен только ваш недолговечный токен доступа, потому что StackOverflow никогда не увидит ваш долгоживущий токен обновления. А вся драма с частотой использования каждого токена — это в лучшем случае отвлекающий маневр.

Answer 20

Сначала клиент аутентифицируется на сервере авторизации, предоставляя разрешение на авторизацию.

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

Сервер ресурсов проверяет токен доступа и предоставляет защищенный ресурс.

Клиент отправляет защищенный запрос ресурса на сервер ресурсов, предоставляя токен доступа, где сервер ресурсов проверяет его и обслуживает запрос, если он действителен. Этот шаг повторяется до истечения срока действия токена доступа.

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

Клиент проходит аутентификацию на сервере авторизации, предоставляя маркер обновления.

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

Answer 21

Есть два важных момента , которые нам необходимо понять, чтобы понять ответ на этот вопрос.

1. Во-первых, иногда токен доступа пользователя может быть украден , и пользователь ничего об этом не знает. Поскольку пользователь не знает об атаке, он не сможет сообщить нам об этом вручную. Тогда будет огромная разница между, например, 15 минутами и целым днем ​​в отношении количества времени (возможности), которое мы дали злоумышленнику для выполнения своих атак. Вот почему нам нужно «обновлять» токены доступа каждый «короткий период времени» (например, каждые 15 минут) , мы не хотим откладывать это на долгое время (например, целый день). Итак, то, что OP сказал в вопросе, явно не вариант (растягивание срока действия токена доступа до тех пор, пока токен обновления).

Итак, у нас остались как минимум два варианта:

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

• Использование токена обновления. Прочтите второй пункт ниже, чтобы понять, как это работает (логика, стоящая за этим).

2. Второй момент, который нужно понять, заключается в том, что поскольку мы отделили токен доступа от токена обновления, теперь токен обновления можно отправить «другим способом» , поэтому мы можем отправить его таким образом, что он будет недоступен для JavaScript злоумышленников (на стороне клиента). код в целом), например, с помощью httpOnlyтеги:

Файл cookie HttpOnly — это тег, добавляемый в файл cookie браузера, который предотвращает доступ клиентских сценариев к данным. источник

Использование флага HttpOnly при создании файла cookie помогает снизить риск доступа сценария на стороне клиента к защищенному файлу cookie. Файлы cookie HttpOnly были впервые реализованы в 2002 году разработчиками Microsoft Internet Explorer для Internet Explorer 6 SP1. источник (спасибо IE!)

Таким образом, хотя злоумышленники могут украсть токены доступа (настоятельно рекомендуется хранить их в оперативной памяти, а не в уязвимых местах, таких как локальное хранилище), они не смогут украсть токены обновления. Таким образом, если злоумышленник украдет ваш токен доступа, у него будет только короткий период времени для злоупотребления им (15 минут? Намного лучше, чем целый день!), а затем, как только он истечет, у него не будет шанс получить свежий самостоятельно , а также.