Как обеспечить токен обновления?

Question

Я использую JWT для аутентификации пользователей моего приложения.Когда пользователь входит в систему, ему предоставляется токен доступа и токен обновления.Чтобы сохранить токен обновления в безопасности, я не храню его на клиентской стороне, но сохраняю его на серверной стороне со своей учетной записью, чтобы к нему было нелегко получить доступ.Я запутался в безопасности маркеров обновления, но вот логику, которую я понимаю, когда читаю онлайн-ресурсы о том, как использовать токены обновления:

1. аутентификация
2. доступ к хранилищутокен + обновить токен где-то (в моем случае, токен доступа на внешнем интерфейсе и токен обновления на внутреннем конце)
3. при выполнении запроса API, проверить токен доступа на стороне API
4. если срок действия маркера истек, используйте токен обновления, чтобы сгенерировать новый токен доступа + новый токен обновления, отправить токен доступа обратно клиенту
5. сохранить токены, как раньше ... и повторить

Вопрос безопасности, который меня беспокоит, заключается в том, что кто-то еще (хакер) захватил токен доступа и отправил с ним запрос в API, если срок действия токена истек, API будет использовать токен обновления дляполучить новый токен доступа + новый токен обновления и вернуть по крайней мере токен доступа хакеру.

Я прочитал эту статью примерно 5-6 раз, и я прочитал эту статью несколько раз, а также некоторые другие статьи на эту тему, все они что-то говорятв соответствии с

убедитесь, что токен обновления надежно хранится, потому что он долговечен, access_token недолговечен, так что не так уж и важно,

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

Есть ли что-то, чего мне не хватает?Как API узнает, кто отправляет запрос, если хакер завладел токеном с истекшим сроком доступа?он все равно отправит новый, используя токен обновления.Я должен как-то проверить, кто отправляет запрос?

---

ОБНОВЛЕНИЕ

Так что я понимаю, что когда запрашивается новый токен доступа, мне нужно отправить поверх токена обновления,идентификатор клиента и секрет клиента.Проблема, с которой я столкнулся, заключается в том, что, как и раньше, хакер может отправить запрос на мой API-сервер, сервер получает от хакера захваченный токен доступа, он увидит, что срок его действия истек, поэтому он отправит токен обновления вместе сclientID / client secret (которые хранятся в виде переменных среды) для API авторизации и возвращают новый токен доступа / токен обновления, что возвращает нас к той же проблеме.

---

ОБНОВЛЕНИЕ 2

некоторые интересные вопросы по теме:

1. Почему у OAuth v2 есть и токены доступа и обновления?
2. https://security.stackexchange.com/questions/87119/how-secure-are-expiring-tokens-and-refresh-tokens

в соответствии со вторым вопросом и ответом, похоже, что токен обновления не является более безопасным способом поддержания доступа, просто легче обнаружитьхакер, потому что токены аутентификации / обновления продолжают получать и аннулировать токены других.Проблема в том, что это произойдет, только если 2 пользователя одновременно пытаются получить доступ к ресурсам - если только хакер окажется активным в данный период времени, он будет иметь неограниченный доступ к данным оригинальных пользователей, пока исходный пользователь не попытается использоватьприложение и доступ к защищенным ресурсам

Answer 1

Вы не должны хранить токен на сервере.Клиент аутентифицируется и получает токен.Вы храните токен в браузерах в файле cookie или localStorage.Каждый запрос авторизуется токеном.Если вы отправляете его по незашифрованному каналу без ssl, он открыт для перехвата.Хакер, получивший токен, позволяет им выдавать себя за пользователя.Токены с истекшим сроком действия не должны позволять повторную аутентификацию без повторного ввода учетных данных пользователя.Токены с истекшим сроком действия следует игнорировать.

Answer 2

По сути, кажется плохой идеей использовать токены обновления с браузерными приложениями. Токены обновления предназначены для мобильных приложений, в которых токен обновления можно безопасно хранить на телефоне - телефоны имеют своего рода механизм безопасного хранения, а браузеры - нет.

Answer 3

Есть хороший документ OAuth 2.0 для приложений на основе браузера , в котором обсуждаются рекомендации для этих приложений.

Я бы выбрал хранение токенов на клиенте или сервере.Смешивая его (сохраняя токены обновления на вашем сервере и токены доступа в браузере), вы создаете собственный протокол со своими собственными уязвимостями.

Если браузерному приложению нужен токен доступа только для доступа к своему бэкэнду, вы можете использоватьВаш бэкэнд как клиент OAuth2 (который получает код авторизации), получает идентификационные данные пользователя, создает файл cookie, который будет поддерживать сеанс между браузером и бэкэндом.Это гораздо проще, чем обменивать, обновлять и проверять токены OAuth2.

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

Серверы авторизации НЕ ДОЛЖНЫ выдавать токены обновления для приложений на основе браузера.

Если сервер авторизации выбирает выдачу токенов обновления для приложений на основе браузера, то он ДОЛЖЕН выдавать новый токен обновления при каждом обновлении токена доступа.ответ.Это снижает риск утечки обновленного токена, поскольку утечка обновления может быть обнаружена, если и злоумышленник, и законный клиент пытаются использовать один и тот же токен обновления.

Приложение браузера может сохранять своитокены в sessionStorage для выживания перезагрузки страницы.

Answer 4

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

1. Создать токен доступа с истекающим сроком действия и обновить токен при входе пользователя в систему и отправить в интерфейсное приложение (Android, IOS, Web App)).
2. Внешнее приложение надежно хранит токен обновления в своей базе данных.
3. Внешнее приложение отправляет токен доступа при каждом запросе, и JWT проверяет его, не обращаясь к базе данных.
4. Аутентификация работает в течение определенного времени для маркера доступа.
5. По истечении этого срока приложение переднего плана отправляет токен обновления на ваш сервер, дополнительно вы проверяете его с помощью JWT, а также проверяете его в базе данных на равенство.
6. Сервер генерирует новый токен доступа и т. Д.

PS: вся связь должна осуществляться через HTTPS.

Моя реализация основана на приведенной выше логике сдоступ к токену, срок действия которого истекает каждые 30 минут, и обновление токена со сроком действия в год.

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

Вам просто нужно обновить токен обновления на сервере всякий раз, когда пользователь отправляет запрос на вход в систему снова.

Answer 5

Если вы храните токен обновления на сервере, ваш сервер должен включить безопасный файл cookie сеанса в ответ аутентификации, чтобы идентифицировать пользователя.Вы можете запретить злоумышленникам извлекать безопасные сеансовые файлы cookie, установив файлы cookie с флагом HttpOnly.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies

Файл cookie не будет маркером обновления.Это был бы какой-то другой сессионный cookie.Один поток приложения, в котором токен обновления не возвращен пользователю, представляет собой одностраничный поток приложения.

https://auth0.com/docs/flows/concepts/single-page-login-flow

В этом потоке обновление токена выполняется с помощью «Тихой аутентификации»."

https://auth0.com/docs/api-auth/tutorials/silent-authentication#initiate-a-silent-authentication-request

Успешный ответ аутентификации , если у пользователя уже есть действительный сеанс в Auth0 и согласия или других запросов не требуется.

Поэтому нам нужно поддерживать сеанс, сохраняя некоторый идентификатор пользователя.

Answer 6

Во второй статье, которую вы связали, говорится, что для обновления токена необходимо опубликовать токен обновления и client_id и client_secret, поэтому в основном вы повторно аутентифицируете пользователя при обновлении токен доступа.

Чтобы использовать токен обновления, сделайте POST-запрос к конечной точке токена службы с grant_type = refresh_token и включите токен обновления, а также учетные данные клиента.