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

654

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

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

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

Дэйв Манкофф
источник

Ответы:

463

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

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

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

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

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

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

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

catchdave
источник
14
Catchdave прав, но подумал, что я бы добавил, что все изменилось с момента его первоначального ответа. Использование SSL теперь является необязательным (это, вероятно, все еще обсуждалось, когда отвечал catchdave). Например, токены MAC (в настоящее время находятся в стадии разработки) предоставляют возможность подписать запрос закрытым ключом, чтобы SSL не требовался. Таким образом, обновления токенов становятся очень важными, так как вы хотите иметь краткосрочные токены Mac.
AlexGad
54
«Токены обновления, если они скомпрометированы, бесполезны, потому что злоумышленнику требуется идентификатор клиента и секрет в дополнение к токену обновления, чтобы получить токен доступа». Но идентификатор клиента и секрет также хранятся в устройстве, не так ли? Таким образом, злоумышленник с доступом к устройству может получить их. Почему? Здесь, github.com/auth0/lock/wiki/Using-a-Refresh-Token , написано, что потеря токена Refresh означает, что он может запросить столько токенов аутентификации, сколько захочет, возможно, не в сценарии googles, но Что делать, если я реализую свой собственный сервер oauth2?
Джамшид Камарудин
42
«Злоумышленнику требуется идентификатор клиента и секрет в дополнение к токену обновления, чтобы получить токен доступа» : тогда в чем разница между использованием токена обновления и простым выходом из системы?
sp00m
34
Токен обновления может быть использован третьей стороной, которая может обновить токен доступа без знания учетных данных пользователя.
Марек Дек
27
@KevinWheeler Нет, идентификатор клиента и секретный ключ являются учетными данными для клиента OAuth, а не для пользователя. Когда речь идет об OAuth, «клиент» - это обычно сервер (например, веб-сервер stackoverflow), который взаимодействует с сервером авторизации или API ресурса (например, провайдер авторизации facebook). Учетные данные пользователя передаются только между пользователем и сервером OAuth API и никогда не известны клиенту. Секрет клиента передается только от клиента на сервер API OAuth и никогда не известен пользователю.
машина тоскует
551

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

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

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

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

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

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

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

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

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

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

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

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

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

компромиссы

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

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

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

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

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

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

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

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

Роман Иманкулов
источник
4
@RomannImankulov Если я правильно понял, обновив токен, мы можем сохранить его в db и удалить его в любое время, когда захотим отозвать доступ, так почему бы не сохранить токены доступа самостоятельно?
Коснков
30
@kosnkov - короткая версия моего поста: если вы сохраняете токен доступа в базе данных, вы обращаетесь к базе данных при каждом запросе вашего API (что может быть или не быть проблемой в вашем конкретном случае). Если вы сохраните токены обновления и сохраните токены доступа «автономными», вы попадете в базу данных только тогда, когда клиент решит обновить токен доступа.
Роман Иманкулов
5
Лично мне не нравится такой подход, который заключается в том, чтобы не использовать базу данных для повышения производительности, если это может поставить под угрозу безопасность (даже если только для временного интервала окна). Нужно иметь возможность немедленно отозвать access_token, если это необходимо, поскольку почти всегда мы имеем дело с конфиденциальной пользовательской информацией (в противном случае мы, скорее всего, не будем использовать OAuth в первую очередь). Интересно, какой подход используют более крупные компании, такие как Facebook и Google.
Tiago
1
Я не до конца понимаю, почему у нас какое-то время должно быть «открытое окно». Почему мы не можем просто отправить запрос на сервер ресурсов, чтобы не принимать токены доступа для этого пользователя? Также я прав, что у вас не может быть поведение токенов обновления, если у вас нет секрета клиента для подписи токенов? Поэтому в принципе вы не можете использовать токены обновления из программного обеспечения на устройствах cliemts js, мобильных настольных приложениях и т. Д.
Игорь Чордаш
1
@PSIXO сервер ресурсов не имеет постоянного хранилища, кроме базы данных и, возможно, локального кэша. Поэтому единственный способ проверить, был ли токен отозван, - это нажать на базу данных, чего пытается избежать весь этот процесс. Что касается вашего второго вопроса, вы не правы. Если у вас есть токен обновления, вы можете запросить новые токены доступа.
Берни
199

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

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

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

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

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

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

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

laalaguer
источник
@laalaguer Есть ли у вас более детальные политики, например, например: не отзывать токен при изменении IP-адреса пользователя (когда мобильный телефон отключается от WiFi и подключается к сети 3G / 4G)?
svlada
65
Это несколько хороших политик и идей, но я не вижу в вашем ответе ничего, что по своей сути требует использования токенов обновления. Все эти функции могут быть реализованы только с помощью токена доступа.
Эверт
12
@Evert, одно из преимуществ использования токенов доступа и обновления заключается в том, что токены доступа могут быть недолговечными, и, следовательно, это не слишком большой компромисс с безопасностью, если им доверять безоговорочно, без проверки с сервером, который их выдал. Это может позволить вам масштабировать свою инфраструктуру так, чтобы некритические ее части могли доверять информации, хранящейся в (подписанном) токене, без прямого доступа к информации учетной записи пользователя.
Ави Черри
7
@Avi Cherry - Да, токен доступа может быть недолговечным, а также может обновляться, если пользователь все еще считается действительным. Для этого не требуется токен обновления.
Рик Джолли,
10
Я полагаю, что этот ответ предполагает, что мы никогда не хотим, чтобы серверы ресурсов сами выполняли расширенный контроль доступа (например, проверяли активность IP для различных баз данных и т. Д.), И вместо этого они могли полагаться только на проверку маркера доступа в полной изоляции. Хотя это может быть очевидно в масштабе (из соображений производительности), это явно не очевидно для всех здесь, учитывая путаницу в других постах и ​​комментариях. Это хороший пост с хорошей информацией, но я чувствую, что он сильно не соответствует первоначальному вопросу. Я рекомендую хотя бы сделать вышеупомянутое предположение явным.
TNE
72

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

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

BT
источник
16
Это интересно, так как в случае с Google, когда вы запрашиваете токен обновления, вы также отправляете идентификатор клиента и его секрет. Так что вы все равно идете на компромисс каждый час.
гниет
1
Александр, на самом деле, чем короче ttl, тем чаще клиенту придется получать новый токен доступа (который требует использования учетных данных клиента). Так что я на самом деле имею в виду «короче» там. Я добавлю записку, чтобы уточнить.
BT
2
«единственная цель» - не моется. Создание TTL-маркера доступа до тех пор, пока у воображаемого обновления-токена будет достигаться точно так же.
Ревень
8
Поскольку стандарт требует , чтобы учетные данные клиента отправлялись вместе с маркером обновления, предпосылка этого ответа просто ложна. «Поскольку токены обновления обычно являются длительными учетными данными, используемыми для запроса дополнительных токенов доступа ... клиент ДОЛЖЕН пройти аутентификацию на сервере авторизации». Также смотрите комментарий @Rots.
Кевин Кристофер Генри
8
А) Я думаю, что вы смешиваете секреты клиентов и секреты пользователей. Секрет клиента никогда не отправляется с пользовательского устройства, только от обращающегося к нему бэкэнд-приложения к бэкэнд-приложению, предоставляющему данные. B) Сервер oAuth, который позволяет предоставлять пароли для публичного клиента (клиент, который не может хранить секрет клиента, такой как нативное приложение или приложение javascript), также предоставит грант обновления для этого общедоступного клиента, поэтому вам не нужно отправьте секрет клиента при обновлении вашего токена. C) Токен обновления предоставляет бэкенду «харт-бит», когда нужно проверить достоверность пользователя!
Андреас Лундгрен
55

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

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

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

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

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

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

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

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

Adversus
источник
1
«Это также показывает, что потеря токена обновления не проблема, потому что идентификатор клиента и секрет неизвестны». Но они мне не нужны. Если у меня есть токен обновления, я могу передать его на сервер приложений. Он добавляет client_id и secret, а затем передает все три службе OAuth. В чем смысл?
3DFace
7
Сервер приложений не предоставляет способ предоставления токена обновления самостоятельно, вы не можете попросить его сгенерировать новый токен аутентификации, предоставив ему токен обновления. Он обновляет сам маркер аутентификации, когда это необходимо, «за кадром».
Adversus
2
Обратите внимание, что вам на самом деле нужен секрет клиента, чтобы получить токен обновления. Возможно, вы думаете о неявном потоке аутентификации, где вам не нужен секрет, но токены обновления не выдаются и не используются в этом случае.
Кевин Кристофер Генри
@KevinChristopherHenry предполагает, что для конечного пользователя, который просто входит на веб-сайт компании XYZ.com, токен обновления не имеет смысла получать новый токен доступа для XYZ.com? Но токеном обновления может быть любая неуловимая строка - например, guid - хранящаяся в таблице, которую можно найти очень быстро. Принимая во внимание, что токен доступа может быть намного длиннее и сложнее для индексации в базе данных. Таким образом, токен обновления МОЖЕТ храниться и иметь преимущества на стороне конечного пользователя. [хотя, поскольку этот вопрос говорит о oauth2, возможно, любые ответы без сторонней службы, действующей от имени какого-либо лица, все равно не актуальны]
Simon_Weaver
почему вы не можете просто передать «Идентификатор клиента» + «Секрет клиента» + «маркер доступа с истекшим сроком», чтобы получить новый маркер доступа?
Мед
37

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


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

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

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

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

Manicode
источник
Это похоже на OpenID Connect и аутентификацию, поэтому я не вижу, как это отвечает на вопрос, касающийся мотивации обновления токена.
слеске
18

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

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

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

Фил
источник
2
«Токены обновления позволяют клиенту только повторную аутентификацию ...» является важным аспектом здесь.
Джеймс
13

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

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

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

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

heymega
источник
4
Вводить такие «претензии» в маркер доступа было бы необычной плохой практикой. Как описано в спецификации , токен доступа «обычно непрозрачен для клиента». У вас есть примеры поставщиков OAuth, которые делают это?
Кевин Кристофер Генри
3
@heymega Когда пользовательская роль понижается с ADMIN до REGULAR_USER, ожидается, что пользовательская роль должна быть отозвана немедленно, а не после истечения срока действия access_token. Таким образом, похоже, что попадание в базу данных при каждом запросе неизбежно.
svlada
@svlada Я полагаю, что это был бы случай, когда приложение, понижающее сущность с ADMIN до REGULAR_USER, (в том же процессе) также должно было отозвать соответствующий токен. то есть, если мы знаем, что претензии будут меняться, мы не ждем истечения срока действия, мы немедленно
отменяем
13

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

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

bitcoder
источник
1
Вы можете отозвать токен доступа, для чего потребуется либо снова войти в систему для получения другого токена доступа, либо использовать токен обновления для получения другого токена доступа. Если токен обновления был недействительным, пользователю придется пройти повторную аутентификацию, чтобы получить новый токен доступа вместе с новым токеном обновления.
Atieh
10
Я не согласен. Токен доступа выдается сервером авторизации, подписывается датой истечения срока действия и отправляется клиенту. Когда клиент отправляет этот токен на сервер ресурсов, сервер ресурсов не связывается с сервером аутентификации для проверки токена; он просто смотрит на дату истечения срока действия в (подписанном и неизмененном) токене. Поэтому независимо от того, что вы делаете на сервере аутентификации, чтобы попытаться «отозвать», серверу ресурсов все равно. Некоторые люди называют клиентский выход из системы отзывом (т. Е. Клиент удаляет свой токен), но имхо это вводит в заблуждение терминологию - мы хотим «отзывать» токен на сервере, а не клиент
биткодер
1
Не говоря о том, что вы не можете написать собственный код, чтобы игнорировать определенные токены (как здесь stackoverflow.com/questions/22708046/… ), но при этом, вероятно, необходимо несколько сетевых поездок с сервера ресурсов на сервер oauth / db каждый раз, когда клиент делает вызов. Вы избегаете этих вызовов, используя вместо этого токены обновления, и я думаю, что это больше соответствует тому, что задумывали авторы.
биткодер
13

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Не в последнюю очередь увидеть этот удивительный ответ


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

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

Мед
источник
2
это сравнение трудно проследить, поскольку вопросы разные 1. «Сколько у меня было 30 возможностей для взлома ключа за 30 минут?» (разве у меня сначала не было ключа как хакера?) 2. «Сколько у меня было 30 возможностей взломать курьера в течение 30 минут?». Какой будет «возможность взлома»? Как хакер, у меня вообще не было ключа?
Cesc
1
Вы правы. Я внес изменения
Дорогая
4

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

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

Ту Ан Ту
источник
2
«используя не только refresh_token, но также client_id и client_secret, чего нет у хакера». 1. предположим, что это только токен доступа, тогда хакеру все еще не нужны client_id и client_secret? 2. если хакер хороший хакер, он может взломать client_id и client_secret. Независимо от этой части, взлом дополнительных вещей не должен иметь значения для сравнения, потому что если его трудно взломать, то также сложно взломать в случае использования только токена доступа ... Короче говоря, вы не сравниваете идентичные ситуации. Вы смешиваете их
Honey
2

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

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

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

Kraming
источник
Я думаю, что это очень важный момент :-) Это также - в некоторой степени - как бы лишает законной силы аргумент здесь auth0.com/docs/tokens/refresh-token/current#restrictions, чтоA Single-Page Application (normally implementing Single-Page Login Flow) should not under any circumstances get a Refresh Token. The reason for that is the sensitivity of this piece of information. You can think of it as user credentials, since a Refresh Token allows a user to remain authenticated essentially forever. Therefore you cannot have this information in a browser, it must be stored securely.
Simon_Weaver
1

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

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

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

Саптарши Басу
источник
0

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

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

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

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

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

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

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


источник
Это фактически не упоминает, откуда происходит токен обновления. Я предполагаю, что второй абзац должен сказать access token + refresh token?
Simon_Weaver