Позвольте мне перейти к вашим вопросам чуть позже и начать с обсуждения всей цели токена обновления.

Итак, ситуация такова:

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

Теперь, чтобы решить эту проблему, нам нужен способ узнать, что запросы поступают от авторизованного пользователя. Итак, мы представили так называемый токен доступа. Итак, теперь, когда пользователь успешно аутентифицирован, ему выдается токен доступа. Этот токен должен быть длинным и очень случайным (чтобы его нельзя было угадать). Здесь на сцену выходит JWT. Теперь вы можете / можете не захотеть хранить какие-либо пользовательские данные в токене JWT. В идеале вы хотели бы просто хранить в JWT очень простые, крайне нечувствительные детали. Манипуляции с хешем JWT для получения сведений о других пользователях (IDOR и т. Д.) Выполняются самим JWT (используемой библиотекой).

Итак, на данный момент наша проблема с авторизованным доступом решена.

Теперь поговорим о сценарии атаки. Скажем, используя всех перечисленных выше пользователей, Алиса, использующая приложение, имеет авторизованный токен доступа, и теперь ее приложение может делать запросы ко всем API и извлекать данные в соответствии с ее авторизацией.

Предположим, КАК Алиса теряет токен доступа или, другими словами, злоумышленник, Боб, получает доступ к токену доступа Алисы. Теперь Боб, несмотря на то, что он не авторизован, может делать запросы ко всем API, к которым Алиса была авторизована.

ЧТО-ТО МЫ ИДЕАЛЬНО НЕ ХОЧЕМ.

Теперь решение этой проблемы:

1. Либо обнаружите, что что-то в этом роде происходит.
2. Уменьшите само окно атаки.

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

Итак, мы пытаемся достичь 2 выше, и, следовательно, мы добавляем истечение срока действия токена доступа, скажем, токен доступа действителен в течение 't' (кратковременного) времени.

Как это помогает? Что ж, даже если у Боба есть токен доступа, он может использовать его, только пока он действителен. Как только он истечет, ему придется забрать его снова. Теперь, конечно, можно сказать, что он может получить это так же, как и в первый раз. Но опять же, нет ничего лучше 100% безопасности!

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

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

Теперь вы можете спросить, Боб также может иметь доступ к токену обновления, аналогично тому, как он скомпрометировал токен доступа. ДА. Он может. Однако теперь становится легко выявить такой инцидент, что было невозможно в случае использования одного только токена доступа, и предпринять необходимые действия для уменьшения нанесенного ущерба.

Как?

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

Конечно, вы все равно можете утверждать, что Боб может снова получить доступ как к токенам обновления, так и к токенам доступа и повторить всю историю, описанную выше, что может привести к DoS-атаке на Алисе, фактическом подлинном клиенте, но опять же, нет ничего лучше 100% безопасности. .

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

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

Вот как это будет работать:

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

   • JWT id
   • ID пользователя
   • айпи адрес
   • пользовательский агент
   • флаг valid (по умолчанию ИСТИНА)
   • создано в
   • обновлено

2. Ваш клиент отправляет JWT в каждый запрос. Пока JWT не истек, он имеет доступ к ресурсам. Если срок действия JWT истек, вы обновляете его за кулисами и возвращаете как ресурс, так и дополнительный заголовок X-JWT с новым JWT.

3. Когда клиент получает ответ с заголовком X-JWT, он отбрасывает старый JWT и использует новый для будущих запросов.

Как обновление JWT работает на сервере

1. Найдите соответствующую запись в базе данных, используя идентификатор JWT.
2. Проверьте, установлен ли по-прежнему флаг valid, в противном случае отклоните.
3. При желании вы можете сравнить IP-адрес запроса и пользовательский агент с сохраненным IP-адресом и пользовательским агентом и принять решение отклонить, если что-то выглядит подозрительно.
4. При желании вы можете проверить поля createdAt или updatedAt записи базы данных и решить не обновлять, если прошло слишком много времени.
5. Обновите поле updatedAt в записи базы данных.
6. Верните новый JWT (который в основном является копией истекшего JWT, но с увеличенным сроком действия).

Этот дизайн также даст вам возможность отозвать все токены для пользователя (например, если пользователь потеряет свой телефон или обновит свой пароль).

Преимущества:

• Вашему клиенту никогда не нужно проверять время истечения срока действия или делать запросы на обновление токенов, все, что он делает, это проверяет заголовок X-JWT в ответах.
• Вы можете добавить настраиваемую логику обновления на основе IP-адреса, пользовательского агента, максимального возраста токена или их комбинации.
• Вы можете отозвать некоторые или все токены для пользователя.

Если бы я БЫЛ использовать токен обновления, разве не было бы выгодно иметь долгосрочное истечение срока действия для хорошей практики и с этим токеном?

Жетоны обновления долговечны, жетоны доступа недолговечны.

Если бы я БЫЛ использовать токен обновления, будет ли этот токен сохраняться с идентификатором пользователя и / или токеном JWT?

Он будет сохраняться как отдельный токен на клиенте вместе с JWT, но не внутри JWT. UserID / UID может храниться внутри самого токена JWT.

Когда я обновляю свой токен каждые 1 час, как это работает? Я хочу создать конечную точку, которая принимает мой токен JWT или мой токен обновления? Обновит ли это дату истечения срока действия моего исходного токена JWT или создаст новый токен?

Да, вам нужен отдельный сервис, который выдает и обновляет токены. Он не обновит истечение срока действия существующего токена JWT. Токен - это просто пары значений поля JSON в кодировке base64. Таким образом, изменение данных меняет вывод. У токена также есть дата выпуска, которая, по крайней мере, будет меняться при каждой новой проблеме (обновлении). Так что каждый токен будет уникальным и новым. Срок действия старых токенов истечет автоматически, поэтому вам необходимо истечь срок действия всех токенов доступа, иначе они останутся навсегда.

Другой ответ здесь гласит, что старые токены уничтожаются, когда вы выпускаете новый токен. Это просто не так. Жетоны нельзя уничтожить. Фактически, вы можете собирать сотни токенов, постоянно связываясь с сервером аутентификации и запрашивая новые свежие токены, используя свой Refresh Token. Каждый из этих токенов доступа будет действителен до истечения срока их действия. Так что истечение срока действия обязательно, и оно должно быть коротким.

Действительно ли нужен токен обновления, учитывая эти детали? Кажется, что если пользователь просто использует токен JWT для получения нового токена (по ссылке выше), то токен обновления устарел.

У токенов JWT есть претензии клиентов. Например, is_manager:true заявка на токен JWT может разрешить доступ к функциям уровня менеджера. Теперь, если вы решите понизить роль пользователя с менеджера до подрядчика, это не вступит в силу немедленно. Пользователь все еще может использовать старый токен. Наконец, когда это истекает, он обращается к серверу аутентификации, чтобы обновить свой токен. Сервер аутентификации выдает новый токен без запроса на управление, и пользователь больше не сможет получить доступ к функциям управления. Это создает окно, в течение которого утверждения пользователя не синхронизируются с сервером. Это еще раз объясняет, почему токены доступа должны быть недолговечными, чтобы синхронизация могла происходить часто.

По сути, вы обновляете проверки авторизации каждые 15 минут, а не проверяете их по каждому отдельному запросу (как обычно работает аутентификация на основе сеанса). Если вам нужны разрешения в реальном времени вместо обновления каждые 15 минут, тогда JWT может не подойти.