Ответ 1

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

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

Ответ 2

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

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

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

• Если у вас есть собственное управление сеансом, сохраните как 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 в браузере, а затем использовать его для прямого доступа к ресурсам пользователя в течение длительного времени.

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

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

• Храните клиента/секрет на устройстве и поддерживайте устройство для получения доступа к пользовательским ресурсам.

• Используйте сервер приложений backend для хранения clientid/secret и выполните его оркестровку. Используйте access_token как своего рода ключ сеанса и передавайте его между клиентом и сервером приложений.

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

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

Длины экспирации

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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

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

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

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

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