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

Question

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

https://tools.ietf.org/html/rfc6749#section-4.2

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

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы

Маркеры обновления частично устраняютSPoF (единичная точка отказа) базы данных Access Token, однако они имеют некоторые очевидные недостатки.

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

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

   без обновить токен

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

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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

1. Пользователь - хороший пользователь, он дома и получаетвкл / выкл ваш сайт покупок и поиска на своем айфоне.Его 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

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

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

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

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

Чтобы получить обновленный токен доступа, клиент использует следующую информацию:

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

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

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

Answer 6

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

---

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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