Влияние токенов обновления на производительность сервера
Я ищу способ правильно реализовать токены обновления и доступа в простом SPA с Dotnet Core Backend. Чем больше я читаю об этом, тем больше я, кажется, беспокоюсь о его влиянии на производительность сервера, особенно по мере роста числа зарегистрированных пользователей.
Возьмите этот пост auth0 и этот Технические характеристики, например, они ясно демонстрируют, что нам нужно создавать новый токен обновления каждый раз, когда мы создаем токен доступа, из-за того, что вредоносный клиент пытается повторно использовать токен обновления.
In particular, authorization servers: MUST rotate refresh tokens on each use, in order to be able to detect a stolen refresh token if one is replayed (described in [oauth-security-topics] section 4.12)
Теперь, учитывая, что мы хотим ограничить время истечения срока действия токена доступа (например, 10-20 минут), и нам нужно сохранять каждый токен обновления, который мы генерируем, чтобы распознавать вредоносную активность повторного использования старого токена обновления.
Это означает, что каждые 20 минут пользователи
Следовательно, после дня входа пользователя в систему мы сохранили: 24 * 60 / 20 = 72 различных токена обновления.. и теперь мы проверяем каждого пользователя по сравнению с каждым ??
Я что-то упустил, как это масштабируется?
@RonvanderHeijden меня беспокоит масштабируемость, но это 1-2 запроса в секунду помимо фактических запросов, сделанных пользователями. Вы также должны искать токены обновления с истекшим сроком действия, чтобы увидеть, есть ли повторная атака, если вы видите такую, которую вы можете сказать, что пользователь был скомпрометирован. Это в посте, на который я дал ссылку: «Затем вредоносный клиент пытается использовать RT1 для получения токена доступа. Auth0 распознает, что RT1 используется повторно, и немедленно делает недействительным семейство RT, включая RT2, поскольку повторное появление RT1 указывает на утечку токена. Важно, чтобы RT2 также был признан недействительным. для предотвращения последующего ущерба..."
Значит, ваш сервер авторизации и ресурсный сервер - это одно и то же?! Опять же, просто проверьте полученный токен. Если он отозван, пользователь скомпрометирован. Нет ни одной причины проверять каждый токен обновления.
Да, это правильно, сервер авторизации и сервер ресурсов для меня одинаковы. Но злоумышленник может получить любой предыдущий токен обновления, даже за несколько месяцев до этого, чтобы узнать, использовался ли он уже, разве мы не должны хранить их все?
Ответы 1
На самом деле вам не нужно хранить каждый когда-либо созданный токен обновления. Вам нужен только список используемых токенов, чтобы проверить, повторно ли используется тот, который ваш пользователь пытается обновить, и, поскольку ваши токены обновления должны иметь срок действия, как и ваши токены доступа, вам также не нужно хранить токены, даже бывшие в употреблении, дольше, чем срок их службы.
- Если пользователь пытается использовать действительный токен обновления: срок его действия не истек и его нет в вашем списке использованных токенов. Хорошо пойти!
- Если пользователь пытается использовать токен с истекшим сроком действия: срок его действия истек, поэтому не нужно беспокоиться о повторном использовании, не нужно проверять базу данных на наличие использованных токенов.
- Если пользователь пытается повторно использовать действительный токен обновления: он находится в вашем списке.
Таким образом, несмотря на то, что он масштабируется в зависимости от количества пользователей, он стабилен с течением времени и не выйдет за пределы пропорции (при условии, что вы очищаете старые токены).
Есть и другие вещи, которые следует учитывать. Как упоминалось в этом другой пост auth0, в случае повторного использования вы хотите аннулировать все семейство токенов, а не просто запретить доступ одному пользователю, который повторно использовал токен (это может быть законный пользователь). Опять же, вам не нужно хранить каждый токен из семейства токенов, чтобы отслеживать, что нужно аннулировать: вам просто нужно добавить идентификатор семейства к своим токенам, пометить сам этот идентификатор семейства как недействительный в случае повторного использования. и отклонить будущие попытки обновления, если они принадлежат недействительному семейству. Список недействительных семейств можно также очистить от всех идентификаторов семейств, признанных недействительными дольше, чем срок действия ваших токенов обновления.
Что касается запросов к серверу, токены обновления должны обеспечивать чистый прирост производительности по сравнению с другими средствами авторизации, такими как ключи API или базовая аутентификация HTTP, поскольку на каждый токен обновления, который вы должны выдать, вы также получаете 20-минутные запросы на что вам не нужно будет запрашивать базу данных, чтобы проверить, действителен ли ключ API, или является ли предоставленный пароль правильным (тем более, что хорошие функции хэширования паролей, такие как bcrypt, намеренно работают медленно).
Вы действительно думаете, что ~ 1-2 запроса в секунду как-то влияют на ваш сервер? И почему вы выбрали недопустимые токены обновления? Просто проверьте тот, который предоставляется ...