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

StackOverflow https://stackoverflow.com/questions/3487991

Вопрос

В разделе 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?

Это было полезно?

Решение

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

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

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

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

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

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

Обновить токены ... смягчает риск утечки проживала access_token (запрос param в файле журнала на сервере небезопасных ресурсов, бета-или плохо закодированного сервера ресурсов сервера, клиентом js sdk на сайте не HTTPS, который помещает Access_token в Cookie и т. Д.)

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Клиент ID.
  • Секрет клиента
  • Токен обновления

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В то время как токен обновления сохраняется сервером авторизации. Токен доступа - это автономный сервер, поэтому ресурсный сервер может проверить его, не сохраняя его, что экономит усилие поиска в случае проверки. Другой момент отсутствует в обсуждении от RFC6749 # Page-55

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой обновленный токен не о?

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

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

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

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

Во-первых, клиент аутентифицируется с сервером авторизации путем предоставления разрешению грант.

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top