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

Я провел некоторое исследование по внедрению JWT для API на основе PHP, который мы создаем, и одна вещь, которая меня больше всего смущает на данный момент, - это токены обновления. Насколько я понимаю, вы получаете как токен доступа, так и токен обновления во время начальной аутентификации, и что токен обновления позволит вам в основном пропустить этот начальный шаг аутентификации, чтобы получить новый новый токен доступа, когда это необходимо. Если я правильно понимаю, обновленные токены, когда они сгенерированы, должны храниться в базе данных в паре с клиентом, который только что аутентифицировал себя. Если мои токены доступа существуют только в течение очень короткого промежутка времени (скажем, 1 минута), означает ли это, что очень загруженный клиент, использующий API, может в конечном итоге запрашивать мое хранилище данных каждую минуту, чтобы выполнить шаг обновления (чтобы проверить, обновляется ли обновление токен существует / еще действителен / не был отозван / и т. д.)? Разве это не было бы так же плохо, как попадание в мою базу данных с каждым запросом?


jwt refresh-token
person georaldc    schedule 26.10.2016    source источник
comment
Вы про oAuth?   -  person Karol Gasienica    schedule 26.10.2016
comment
Просто JWT и токены обновления в целом. На самом деле, я думаю, это скорее вопрос о токенах обновления.   -  person georaldc    schedule 26.10.2016

Ответы (2)


arrow_upward
0
arrow_downward

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

  • Срок годности после первого использования
  • Срок действия истекает через заданный промежуток времени (например, 14 дней), поэтому с одним токеном обновления вы можете сгенерировать множество токенов доступа
  • Никогда не истекает, можно только отозвать (например, путем создания нового токена обновления)

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

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

Пример

<?php
$m = new Memcached();
$m->addServer('localhost', 11211);

$user_id = 1;    
$refresh_token = $m->get($user_id."_refresh_token")

if (!refresh_token) {
    if ($m->getResultCode() == Memcached::RES_NOTFOUND) {
        $token = 'Some SQL query to get refresh token';
        $m->set($user_id."_refresh_token", $token );
        $refresh_token = $m->get($user_id."_refresh_token");
    } else {
        /* log error */
        /* ...       */
    }
}
person Karol Gasienica    schedule 27.10.2016
comment
Как мне принудительно аннулировать токен обновления, если он был кэширован? Разве для этого не потребуется постоянная проверка состояния каждый раз, когда используется токен обновления? Я думал о коротком времени жизни токена доступа так, чтобы я мог в случае необходимости как можно скорее изменить область действия для каждого пользователя. Разве это не одна из проблем с токенами доступа, срок действия которых не истекает в течение длительного периода времени. - person georaldc; 27.10.2016
comment
В моем примере показано, нет ли токена вообще в memcached, но вы всегда можете перезаписать ключ в memcached новым токеном, если текущий токен обновления не работает с некоторыми из ваших валидаторов (например, истек или отозван). Я также думаю об использовании токена JWT в качестве токена обновления, это может сработать, потому что в токене JWT хранятся данные, такие как время истечения срока, области и другие, которые вы можете определить. В любом случае вам нужно будет всегда проверять токен доступа при использовании. Когда он истекает или недействителен, вы можете попытаться создать новый, вы можете попробовать сделать это один раз, когда он снова не удастся, вы можете просто вернуть false. - person Karol Gasienica; 27.10.2016

arrow_upward
0
arrow_downward

Маркер доступа похож на кеш БД для вашей пользовательской БД, а время истечения срока действия - это TTL для этой записи в кеше. Думайте о времени истечения срока действия токена доступа как о том, как часто нужно проверять пользователя на соответствие пользовательской БД. Если вы получите высокую нагрузку на свою пользовательскую БД, вы просто увеличите время истечения срока действия ваших токенов доступа.

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

person Andreas Lundgren    schedule 27.10.2016