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

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

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

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

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

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

Представим, что кому-то удалось захватить вашу сессию. Единственное, что можно - это запросить свои страницы.

2. если у вас нет управления сеансом, поместите 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) Здесь нет большой разницы между коротким и длинным токеном доступа, поскольку он скрыт на сервере приложений. Во 2) кто-то может получить 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. Некоторым нравится stackflow. Решение об истечении срока действия - это компромисс между простотой использования и безопасностью. Длина токена обновления связана с длиной, возвращаемой пользователем, т. Е. Задайте для обновления, как часто пользователь возвращается в ваше приложение. Если срок действия токена обновления не истекает, единственный способ их отзыва - это явный отзыв. Обычно вход в систему не отменяется.

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

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

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

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

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

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

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

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

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

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

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