Как защитить токен обновления от хакера

Question

Я много гуглил о том, как защитить refresh_token от хакера, потому что он будет храниться где-то в браузере local-storage / cookie, поэтому хакер может легко украсть эти токены, и я не смог найтиправильный ответ, поэтому я пришел сюда.

Я понимаю, что срок действия access_token истечет через меньшее время, и мы должны использовать refresh_token, чтобы получить новый access_token.Но если хакеры украдут средства refresh_token, он может оставаться в качестве пользователя для входа в систему в течение длительного времени, верно?

Некоторые люди говорят, что вы можете защитить его, используя client_id и client_secret, нохакер собирается получить доступ к конечной точке API, которая имеет client_id и client_secret.Итак, еще раз, хакер может легко получить новый access_token.

Так что я не нахожу способа защитить хакера от получения нового access_token.

Может ли кто-нибудь помочь мне здесь,о том, как защитить хакера от получения доступа к токену обновления из браузера local-storage / cookie?

Answer 1

В контексте вашего объяснения вы говорите о браузерном приложении.Если это приложение не имеет серверной части, у вас нет безопасного места для хранения ваших долгоживущих токенов или клиентских секретов.

С точки зрения OAuth 2.0 они называются общедоступными клиентами..Таким образом, протокол не позволяет им иметь секрет клиента.Таким образом, у них есть идентификатор клиента и URL-адрес перенаправления для аутентификации клиента (идентификации клиента).Неявный поток - это один поток ключей, подходящий для SPA, который запускается в браузере.По спецификации они не получат токен обновления.Причина в том, что они не могут защитить такие секреты.

Но если у вас есть бэкэнд и вы можете соотнести сеанс браузера и внутреннее хранилище, вы можете использовать поток, который дает ваш токен обновления и надежно хранит его.Но для этого требуется, чтобы ваша прикладная архитектура поддерживала такое (например: - сеанс браузера и внутреннее хранилище).

Кроме того, вместо того, чтобы каждый раз входить в систему для конечного пользователя, вы можете использовать состояние входа сервера идентификации для пропуска журнала.in. Это также будет зависеть от файла cookie браузера сервера идентификации и его времени жизни.Например, сервер идентификации может иметь сеанс браузера, действительный в течение 24 часов.Таким образом, ваш клиент не увидит страницу входа при обращении к приложению w в течение определенного времени.

Answer 2

Вы можете попытаться защитить локальное хранилище, используя эту библиотеку Secure-ls