Несколько сценариев могут помочь проиллюстрировать цель доступа и обновления токенов и технические компромиссы при разработке системы oauth2 (или любой другой аутентификации):
Сценарий веб-приложения
В сценарии веб-приложения у вас есть несколько вариантов:
- если у вас есть собственное управление сеансом, сохраните и access_token, и refresh_token для идентификатора сеанса в состоянии сеанса в службе состояний сеанса. Когда пользователь запрашивает страницу, требующую доступа к ресурсу, используйте access_token, а если срок доступа access_token истек, используйте refresh_token, чтобы получить новый.
Давайте представим, что кому-то удается угнать ваш сеанс. Единственное, что возможно - это запросить ваши страницы.
- если у вас нет управления сессиями, поместите 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 в браузере, а затем использовать его для прямого доступа к ресурсам пользователя в течение длительного времени.
Мобильный сценарий
На мобильном телефоне есть несколько известных мне сценариев:
Сохраните клиентские данные / секретные данные на устройстве и организуйте доступ к ресурсам пользователя.
Используйте бэкэнд-сервер приложений, чтобы держать клиент / секрет и заставить его выполнять оркестровку. Используйте access_token как своего рода сеансовый ключ и передайте его между клиентом и сервером приложений.
Сравнивая 1 и 2
В 1) Когда у вас есть клиент / секрет на устройстве, они больше не являются секретом. Любой может декомпилировать, а затем начать действовать так, как будто это вы, с разрешения пользователя, конечно. Access_token и refresh_token также находятся в памяти и могут быть доступны на скомпрометированном устройстве, что означает, что кто-то может выступать в качестве вашего приложения, не предоставляя пользователю свои учетные данные. В этом сценарии длина access_token не влияет на возможность взлома, так как refresh_token находится в том же месте, что и access_token. В 2) клиент / секрет или токен обновления скомпрометированы. Здесь длина срока действия access_token определяет, как долго хакер сможет получить доступ к ресурсам пользователей, если они получат его.
Длина истечения
Здесь все зависит от того, что вы защищаете своей системой аутентификации, и от того, как долго должен истекать срок действия вашего access_token. Если это что-то особенно ценное для пользователя, оно должно быть коротким. Что-то менее ценное, это может быть дольше.
Некоторые люди, такие как Google, не имеют срока действия refresh_token. Некоторым нравится стекопоток. Решение об истечении срока действия является компромиссом между простотой и безопасностью пользователя. Длина маркера обновления связана с длиной возврата пользователя, т. Е. Установите для обновления частоту, с которой пользователь возвращается в ваше приложение. Если токен обновления не истекает, единственный способ, которым они отозваны, - с явным отзывом. Обычно вход в систему не отменяется.
Надеюсь, что довольно длинный пост будет полезен.