Я не могу понять аутентификацию JWT хорошо

Question

В настоящее время многие разработчики используют аутентификацию JWT для авторизации вызова API. Кстати, если хакер может перехватить запрос вызова API аутентифицированного пользователя, он может иметь аутентифицированный токен JWT. Затем хакер может получить доступ к этому API с авторизованным токеном JWT без аутентификации. Это хорошо? Мне интересно, что аутентификация JWT на самом деле безопасна. Вы можете это объяснить?

Answer 1

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

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

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

Но если это произойдет, то что?

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

Другим вариантом является проверка токена при каждом запросе. Это требует больше ресурсов (например, поиск в базе данных), хотя вы можете использовать какой-то вид кэширования. Если что-то меняется, например, по IP-адресу, вы можете сделать токен недействительным. Но вопрос в том, можете ли вы определить, был ли токен отправлен хакером.

Так что это зависит от выбранной стратегии. Но: если вы выдадите долгоживущий токен доступа без проверки (и, следовательно, без возможности отозвать токен), то у вас возникнет проблема, если хакер завладеет токеном доступа. Так что вам нужно что-то сделать, чтобы использовать это безопасным способом.

Хотя я думаю, что этого должно быть достаточно, чтобы помочь вам понять, я хотел бы упомянуть использование токенов обновления. Если вы используете краткосрочные токены доступа, то вы можете захотеть реализовать долгоживущие токены обновления. Эти токены обновления предназначены для получения нового токена доступа после его истечения. Преимущество в том, что вам не нужно отправлять учетные данные, достаточно токена refesh. Однако вы можете реализовать это только в приложении, которое может хранить секрет. Потому что вы наверняка не хотите, чтобы хакер перехватил (долгоживущий) токен обновления.

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

Answer 2

JWT - это всего лишь безопасный переносчик сообщений между сервером fsb и клиентом, так что сервер fsb может определить, вошел ли клиент в систему или нет; при входе в систему сервер fsb будет извлекать персональные уникальные пользовательские данные.

1. Google OAUT

   1. G отправляет обратно gid пользователя на мой сервер, только если пользователь имеет учетную запись google и успешно вводит gmail и пароль правильно.
   2. идентификатор пользователя сохраняется в полезной нагрузке jwt.

2. JWT

   3. если Google подтверждает пользователя и Google возвращает GID
   4. создавать контент jwt и внутреннее сопровождение: дата истечения, шифрование
   5. jwt отправляется и хранится в локальном хранилище браузера пользователя;
   6. запрос каждого пользователя отправляет JWT обратно на мой сервер
   7. мой сервер декодирует jwt, используя secretOrKey, который есть только на моем сервере, и получает содержимое (uid) от jwt.
   8. если uid находится в моей базе данных, пользователь уже зарегистрирован и сейчас авторизован.
   9. отправить запрошенные данные из моей базы данных пользователю, потому что он вошел в систему
   10. если использование не проходит проверку Google из-за неправильного пароля или электронной почты G, jwt не создается.

3. Процесс JWT

   11. всплывающее окно входа пользователя в Google
   12. Сервер Google возвращает информацию на мой сервер. Если gid отсутствует в моей базе данных, я сохраню его в своей базе данных, чтобы пользователь мог быть зарегистрирован.
   13. создать JWT и добавить UID в качестве содержимого. Годен.
   14. JWT отправляется и хранится в локальном хранилище браузера пользователя
   15. пользователь запрашивает страницу через http, она включает в себя jwt. мой сервер проверяет, вошел ли этот пользователь в систему или нет, с помощью теста определения входа в систему: если jwt uid пользователя находится в моей БД, пользователь входит в систему. Запрошенные пользователем данные будут переданы пользователю. Если у пользователя нет jwt или uid не совпадает, то пользователь не вошел в систему, отправьте пользователя на страницу входа.

Описания JWT

1. https://medium.com/@rahulgolwalkar/pros-and-cons-in-using-jwt-json-web-tokens-196ac6d41fb4
2. https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
3. https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
4. https://auth0.com/blog/cookies-vs-tokens-definitive-guide/