Почему срок действия токенов истекает?


209

Я только начинаю работать с Google API и OAuth2. Когда клиент авторизует мое приложение, мне выдают «токен обновления» и недолговечный «токен доступа». Теперь каждый раз, когда срок действия токена доступа истекает, я могу отправить свой токен обновления в Google, и они предоставят мне новый токен доступа.

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

Кроме того, срок действия маркера обновления истекает?

См. Использование OAuth 2.0 для доступа к API Google для получения дополнительной информации о рабочем процессе Google OAuth2.

Ответы:


226

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

  • Многие провайдеры поддерживают токены на предъявителя, которые очень слабы с точки зрения безопасности. Делая их недолговечными и требующими обновления, они ограничивают время, в течение которого злоумышленник может использовать украденный токен.
  • При крупномасштабном развертывании не требуется выполнять поиск в базе данных при каждом вызове API, поэтому вместо этого они выдают самокодированный токен доступа, который можно проверить путем расшифровки. Однако это также означает, что нет возможности отозвать эти токены, поэтому они выдаются на короткое время и должны быть обновлены.
  • Токен обновления требует проверки подлинности клиента, что делает его сильнее. В отличие от вышеупомянутых токенов доступа, он обычно реализуется с помощью поиска в базе данных.

4
Два вопроса: 1) В случае с мобильными приложениями требование к аутентификации клиента делает его сильнее? Поскольку client_secret является частью исходного кода приложения, то это вовсе не секрет. Если предположить, что маркер доступа также используется только по протоколу TLS (и ваш первый пункт не применяется), есть ли дополнительная безопасность? 2) Предполагая, что все это имеет место в нашем сценарии (только TLS, без самокодируемых невозвратных токенов), можно ли выдавать токены доступа, срок действия которых не истек?
Тило

4
Что такое токен на предъявителя и какое отношение он имеет к токенам обновления и доступа?
allyourcode

7
@ Thilo Я думаю, что идея в том, что токены доступа не должны быть отозваны. Как указывает Эран, это позволяет запрашиваемой службе решить, обслуживать ли запрос <em> без необходимости поиска токена доступа в какой-либо базе данных </ em>. AFAICT, это реальное преимущество разделения токенов обновления и токенов доступа.
allyourcode

5
Как недопустим токен доступа (на предъявителя?)? Если я сделаю запрос с токеном носителя с истекшим сроком действия, токен обновления вернет свежий токен носителя. Аналогичным образом, если я украду чей-то токен из их файлов cookie и подделаю свой собственный файл cookie с этим маркером, я отправлю его на сервер, он обновится и отправит мне новый. Что остановить это? Не говорите IP-адрес или даже MAC, потому что это неразумно.
Суамер,

3
@ Суамере, это уже объяснялось. Токены на предъявителя проверяются криптографическим процессом, который не касается базы данных аутентификации, что делает их намного более эффективными для частого доступа к ресурсам. Токены обновления проверяются в процессе, который включает проверку базы данных, чтобы убедиться, что она все еще действительна. Теперь подумайте о том, как работает Gmail. Если кто-то входит в вашу учетную запись из неожиданного географического местоположения, вы можете получить уведомление. Вы можете увидеть все местоположения, которые могут иметь текущие токены обновления. Вы можете выйти из всех местоположений, аннулировав все остальные токены обновления.
Бон

33

Несколько сценариев могут помочь проиллюстрировать цель доступа и обновления токенов и технические компромиссы при разработке системы oauth2 (или любой другой аутентификации):

Сценарий веб-приложения

В сценарии веб-приложения у вас есть несколько вариантов:

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

Давайте представим, что кому-то удается угнать ваш сеанс. Единственное, что возможно - это запросить ваши страницы.

  1. если у вас нет управления сессиями, поместите access_token в cookie и используйте его как сессию. Затем, когда пользователь запрашивает страницы с вашего веб-сервера, отправьте access_token. Ваш сервер приложений может обновить access_token, если это будет необходимо.

Сравнивая 1 и 2:

В 1 access_token и refresh_token путешествуют только по проводам между сервером авторизации (в вашем случае Google) и сервером приложений. Это будет сделано по безопасному каналу. Хакер может захватить сеанс, но он сможет взаимодействовать только с вашим веб-приложением. Во 2 хакер может убрать access_token и сформировать свои собственные запросы к ресурсам, к которым пользователь предоставил доступ. Даже если хакер завладеет access_token, у него будет только короткое окно, в котором он сможет получить доступ к ресурсам.

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

Давайте представим, что вы реализуете oauth2 и установили длинный тайм-аут на токене доступа:

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

Мобильный сценарий

На мобильном телефоне есть несколько известных мне сценариев:

  1. Сохраните клиентские данные / секретные данные на устройстве и организуйте доступ к ресурсам пользователя.

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

Сравнивая 1 и 2

В 1) Когда у вас есть клиент / секрет на устройстве, они больше не являются секретом. Любой может декомпилировать, а затем начать действовать так, как будто это вы, с разрешения пользователя, конечно. Access_token и refresh_token также находятся в памяти и могут быть доступны на скомпрометированном устройстве, что означает, что кто-то может выступать в качестве вашего приложения, не предоставляя пользователю свои учетные данные. В этом сценарии длина access_token не влияет на возможность взлома, так как refresh_token находится в том же месте, что и access_token. В 2) клиент / секрет или токен обновления скомпрометированы. Здесь длина срока действия access_token определяет, как долго хакер сможет получить доступ к ресурсам пользователей, если они получат его.

Длина истечения

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

Некоторые люди, такие как Google, не имеют срока действия refresh_token. Некоторым нравится стекопоток. Решение об истечении срока действия является компромиссом между простотой и безопасностью пользователя. Длина маркера обновления связана с длиной возврата пользователя, т. Е. Установите для обновления частоту, с которой пользователь возвращается в ваше приложение. Если токен обновления не истекает, единственный способ, которым они отозваны, - с явным отзывом. Обычно вход в систему не отменяется.

Надеюсь, что довольно длинный пост будет полезен.


о МОБИЛЬНОМ СЦЕНАРИИ не имеет значения, если вы храните идентификатор клиента на вашем сервере. так что любое другое приложение просто может отправить запрос на ваш сервер и может получить доступ к ресурсам пользователей через ваш сервер, так что его тоже самое
Amir Bar

правда, но тогда они имеют доступ только к предоставляемым вами средствам, а не к полному доступу к базовому токену. Т.е. они могут выдавать себя за ваше приложение. Зачастую токены могут иметь широкие разрешения, тогда как вам требуется только подмножество. Удержание токена в бэкэнде дает дополнительные ограничения, если вам это нужно.
Эд Сайкс

11

В дополнение к другим ответам:

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

Примеры таких рисков в реальной жизни:

  • Серверы ресурсов, как правило, являются распределенными серверами приложений и, как правило, имеют более низкий уровень безопасности по сравнению с серверами авторизации (более низкая конфигурация SSL / TLS, меньшая степень защиты и т. Д.). Серверы авторизации, с другой стороны, обычно считаются критически важной инфраструктурой безопасности и подвергаются более серьезной защите.

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

  • Приложения Backend RS могут быть переданы сторонним организациям, более или менее заслуживающим доверия.

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

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


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

9

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

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


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

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

9
@Spike Верно, но разве в приложение не встроены идентификатор клиента и секрет?
Энди

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

3
Это может привести к тому, что меня задержат, но если это будет отправлено через SSL, это не добавит еще один возможный уровень безопасности. Я предполагаю, что все знают, что такое SSL.
Дэймон Дрейк
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.