Когда следует внедрять токен refre sh и как оставаться без гражданства?

Question

Я внедряю систему аутентификации. В настоящее время система работает с JWT и без токена refre sh. Чтобы позволить пользователю оставаться в системе в течение разумного периода времени, мы решили установить срок действия токена на 12 часов. Я видел, что рекомендуемое время истечения срока составляет 15 минут.

Мой первый вопрос : каждое приложение, которое хочет, чтобы пользователь оставался в системе более 15 минут, должен реализовать токен refre sh? И если это так, то это единственная причина, по которой аннулирование - это единственная причина, или способ безопасности (сохранение токена refre sh в httponly cook ie и JWT в памяти вместо того, чтобы выставлять токен в cook ie). Причина тоже?

Когда я искал преимущества токена refre sh, я в основном видел, что люди говорили об отзыве и рассматривали способ безопасности как деталь реализации токена refre sh, а не как преимущество. Но, насколько я понимаю, это также одно из преимуществ токена refre sh.

Я не нашел стандарта времени истечения срока действия для JWT без токена refre sh. Интересно, это потому, что слишком опасно не реализовать токен refre sh в больших системах с точки зрения безопасности.

Мой второй вопрос : возможно ли реализовать refre sh и оставаться без состояния, добавив утверждения идентичности в токен refre sh (чтобы я мог сгенерировать новый JWT, не затрагивая БД) и отказаться от отзыва? Это недостаток безопасности?

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

Мой третий вопрос : если я не реализую возможность отзыва токена, ожидайте от преимущества безопасности, которое я упомянул в первом вопросе, есть ли причина использовать токен refre sh, а не только создать новый JWT с новым сроком действия каждый раз, когда система получает запрос?

Answer 1

Токен refre sh имеет смысл использовать только в том случае, если вы можете защитить его способом, отличным от токена доступа. Если они хранятся одинаково на клиенте, пользы будет очень мало (есть некоторые, связанные с уязвимостями TLS, но, вероятно, не так много, чтобы поддерживать реализацию отдельного токена refre sh).

Итак по этой причине токен refre sh обычно хранится только в HTTP-файле cook ie, чтобы он был защищен от XSS. Токен доступа также лучше всего хранить таким образом, но тогда вы не сможете отправить его в другое место.

Отзыв - это другой вопрос. Вы не можете отозвать токены без сохранения состояния, поэтому, если вам нужен отзыв токена, вам придется реализовать решение с отслеживанием состояния. Это может быть с токенами refre sh или без них, с точки зрения безгражданства не имеет значения, какой из них вы отзываете.

Итак, хотя вы всегда должны учитывать свою собственную модель угроз (какие угрозы вы хотите смягчить, в какой степени и как), в качестве основного c эмпирического правила вы должны

• реализовать простой старый сеанс с отслеживанием состояния с отправкой клиенту только идентификатора сеанса (не токенов каких-либо kind), если вам не нужно безгражданство (большинство приложений на самом деле не нуждаются в этом), И вы всегда просто отправляете токен его источнику (у вас нет единого входа или аналогичного, где токен получен из чего-то вроде поставщик удостоверений или сервер проверки подлинности используется в разных службах).
• Реализуйте токены доступа, хранящиеся в файлах cookie httpOnly, если вам действительно нужно быть без гражданства, но у вас нет отдельного сервера удостоверения / проверки подлинности или единой подписи. on, и вы всегда просто отправляете токен его источнику.
• Реализуйте краткосрочные токены доступа, хранящиеся Javascript (например, в localStorage) с сохраненными долгоживущими токенами refre sh или идентификатором сеанса, хранящимся в httpOnly cook ie для поставщика аутентификации / идентификации, если вам нужен единый вход / федеративная идентификация, ИЛИ если у вас есть несколько служб, которые будут использовать свой токен доступа. В этом случае вы по-прежнему можете рассматривать более долгоживущие токены доступа без токена refre sh, но вы рискуете скомпрометировать токен, и у злоумышленников будет больше времени, чтобы фактически их использовать. Вы можете попытаться смягчить это с помощью отзыва, но дело в том, что вы, скорее всего, не заметите вовремя, поэтому я считаю это слабым смягчением. А приложение средней сложности Javascript, вероятно, будет уязвимо для XSS (независимо от используемой структуры, но некоторые из них более вероятны).

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

Answer 2

Относительно ваших вопросов:

1. Если вы хотите, чтобы пользователи оставались в системе дольше, то использование токена refre sh является одним из подходов. Я встречал людей в Stack Overflow, которые выполняли обновление токена sh на основе токена аутентификации каждые 10 минут или около того, но я считаю, что этот подход немного сложнее, чем токен refre sh. Я также могу представить, чтобы открыть сеанс на сервере аутентификации, поместить идентификатор сеанса в Cook ie и обновить sh токен аутентификации JWT на основе сеанса. Нет ничего плохого в том, чтобы сделать это вот так.

2. Да. Поскольку токены подписаны, вы также можете поместить информацию для будущей авторизации в токен. (Не добавляйте ничего конфиденциального, так как эта информация будет видна всем). Просто подумайте о том, как должна себя вести система, например, при изменении прав доступа пользователя. Можно ли пользователю работать со своими правами доступа до тех пор, пока он не выйдет из системы? Предположим, вы случайно дали пользователю права администратора. Вы бы хотели, чтобы они были отозваны с помощью следующего токена аутентификации JWT, не так ли?

3. Итак, вы хотели бы, чтобы токен аутентификации длился до тех пор, пока refre sh токен? Замечание произойдет немедленно. Мир все еще вращался бы, и солнце все еще светило бы. Мы делаем это разделение на токены auth и refre sh, потому что мы хотим иметь возможность лучше справляться с кризисными ситуациями. Токен авторизации - это то, что вы всегда используете везде. Если одна из служб пропускает токены в publi c, вы не хотите, чтобы все данные ваших пользователей раскрывались за считанные минуты. Если через несколько минут токены станут недействительными, то даже в случае их утечки у злоумышленника есть небольшое временное окно для выполнения атаки.