🔓****JWT. Часть 1 — Что это вообще такое и зачем нужно Когда пользователь логинится в приложение, серверу нужно как-то понимать, кто отправляет следующие запросы. Например: POST /login { "login": "dima", "password": "123456" } Сервер проверяет логин и пароль. Всё хорошо. Но дальше пользователь отправляет: GET /api/orders И серверу снова нужно понять: Кто делает этот запрос? Конечно, можно было бы передавать логин и пароль с каждым запросом, но это и неудобно, и небезопасно. Один из вариантов решения — JWT. JWT расшифровывается как: JSON Web Token После успешного входа сервер может выдать клиенту токен: { "accessToken": "eyJhbGciOi..." } А клиент дальше отправляет его вместе с запросами: GET /api/orders Authorization: Bearer eyJhbGciOi... Сервер получает токен, проверяет его и понимает, от имени какого пользователя пришёл запрос. JWT можно представить как цифровой пропуск. На нём условно написано: userId: 42 role: USER действует до: 18:00 Когда человек приходит в офис, ему не нужно каждый раз показывать паспорт и заново доказывать, кто он. Он показывает пропуск. Примерно так же работает и токен. Сам JWT обычно выглядит примерно так: xxxxx.yyyyy.zzzzz Внутри него три части: HEADER.PAYLOAD.SIGNATURE То есть: заголовок.данные.подпись Если совсем коротко: JWT — это токен, с помощью которого клиент может передать серверу информацию о своей аутентификации, а сервер может проверить, что токен настоящий и его данные не были незаметно изменены. Но здесь появляется интересный вопрос: Если внутри JWT находятся данные пользователя, может ли пользователь сам открыть токен и поменять, например, role: USER на role: ADMIN ? Вот для ответа на этот вопрос в следующей части разберём, что именно находится внутри HEADER, PAYLOAD и SIGNATURE.