2016-01-03 2 views
2

Я слежу за этим сообщением в блоге (https://auth0.com/blog/2015/04/09/adding-authentication-to-your-react-flux-app/) и смущен в аспекте JWT.Аутентификация с JWT

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

Мне интересно, что мешает кому-то добавить поддельный файл cookie JWT, чтобы получить доступ к аутентифицированной части приложения? Я должен упустить что-то очевидное. Другими словами, поддерживая сеанс, как внешний интерфейс гарантирует, что JWT - это тот, который был «подписан сервером» или что-то еще, а не тот, который был создан для мошенничества, чтобы попытаться получить доступ?

+2

«Мне интересно, что мешает кому-то добавить поддельный файл cookie JWT, чтобы получить доступ к аутентифицированной части приложения?» --- какой ключ вы бы использовали, чтобы подписать его? – zerkms

+0

Итак, когда JWT хранится как файл cookie на интерфейсе, перед выполнением любого запроса сервер проверяет, подписан ли этот JWT с его ключом, и если да, то позволяет? –

+0

«сервер проверяет, подписан ли этот JWT с его ключом, и если да, то разрешает ли это?» --- да. Другими словами - вы не можете доверять никому, отправленному с клиента. – zerkms

ответ

3

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

Сервер back end закодировал JWT с помощью ключа, который не должен существовать на переднем конце, а когда вы передаете JWT обратно на сервер, сервер будет декодировать его перед обработкой вашего запроса. Поэтому он знает, что раньше кто-то использовал ваши учетные данные, отправил JWT в ответ и что кто-то снова отправляет его JWT. Это блокирует атаки вашего API от людей без (реального) JWT.

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

Но это только одна часть более крупного решения безопасности.

2

Ключом к безопасности JWT является «секрет» - ключ, который должен находиться только на доверенных серверах (или с вашим провайдером проверки подлинности, если используется сторонняя организация). JWT шифруются с использованием этого тайны. Это может быть парольная фраза, но JWT также поддерживает шифрование с открытым/закрытым ключом, поэтому секрет может также быть закрытым ключом.

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