Генерация токенов refre sh и токенов доступа на сервере узлов

Question

Я создаю мобильное и веб-приложение. Оба приложения будут общаться с сервером узла. Я использую JWT для аутентификации.

В настоящее время у меня есть следующий код для генерации токена доступа:

const token = jwt.sign({ user: body }, "top_secret");

Я действительно запутался в использовании токенов refre sh и токенов доступа:

1. Как создать токен refre sh?
2. Как выглядит токен refre sh?
3. Можно ли создать токен refre sh - аналогично тому, как я создаю токен доступа?
4. Используется ли токен refre sh только для создания нового токена доступа?
5. Можно ли использовать токен refre sh в качестве токена доступа?
6. Как сделать недействительным токен доступа

7. Как сделать недействительным токен refre sh? Примеры, которые я видел, использовали базы данных для хранения токенов refre sh. Токены refre sh удаляются, если вы хотите аннулировать токен доступа. Если токен refre sh будет сохранен в базе данных модели пользователя для доступа, правильно? Похоже, что в этом случае он должен быть зашифрован

8. Когда пользователь входит в мое приложение, должен ли я отправлять как токен доступа, так и рефрэйр sh токен? Я где-то читал (не могу вспомнить, где), что не рекомендуется отправлять токен доступа и обновлять токен sh.

9. Если отправлять оба токена доступа и refre sh токенов плохо, когда вы отправляете refre sh клиенту? Должна ли быть конечная точка, где клиенты запрашивают токен доступа?
10. Какое хорошее время истечения для токенов доступа и refre sh toekns

Answer 1

Обратите внимание, что в типичном сценарии OAuth2 ios сервер, выдающий токены (сервер авторизации), и сервер API, использующий токены доступа (сервер ресурсов), не совпадают. См. Также: Роли Oauth2 .

Чтобы ответить на ваши вопросы:

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

2. С https://tools.ietf.org/html/rfc6749#section -1.5 ,

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

3. Можно, но refre sh токены, как правило, не являются структурированными токенами (например, JWT), поскольку они потребляются одним и тем же сервер, который их выдал.

4. да

5. нет

6. Если вы не используете жетоны самоанализа , нет хорошего способа их аннулировать. Просто уменьшите срок их службы.

7. Удалите if из хранилища сервера авторизации. Если токен refre sh не найден на сервере, его нельзя использовать для обновления токена доступа sh. Токен refre sh обычно является первичным ключом записи базы данных, содержащей данные о клиенте, пользователе и срок действия токена refre sh. Хотя вы не хотите пропускать ваш refre sh токен, обычно для этого требуется, чтобы клиент использовал их для представления учетных данных клиента.

8. Пользователь входит в систему при авторизации сервер. Он возвращает токен доступа и refre sh токен (если ваш клиент конфиденциальный ) для клиента. Клиент использует только токен доступа для доступа к вашим данным на сервере ресурсов.

9. Ваш клиент использует токен refre sh при обращении к серверу авторизации для получения нового токена доступа , Таким образом, ваш клиент отправляет только токен доступа на сервер ресурсов и только токен refre sh на сервер авторизации.

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