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