Как сделать Private Routes с авторизацией через JWT token

[mavir]

Дописали бы статью, а то "dsadads" да "fdsfdsfdfds" улыбнуло.

[Anastasia__kot]

спасибо, всё правильно поняли) это была неудачная попытка перенести черновик статьи с компьютера в мобильное приложение)

[DmitryKazakov8]

Надо упомянуть, что схема не будет работать с SSR - кука будет прикреплена к домену jsonplaceholder.typicode.com , а не домену фронта, так что node-сервер не сможет ее получить и зафорвардить в апи. Также и из локалстораджа он не получит токен. То есть для SSR юзер всегда будет неавторизован. Конечно, для авторизованных зон SSR зачастую избыточен, но ряд сайтов (маркетплейсы, к примеру) от этого пострадают, хотя и не слишком сильно.

[Nabusteam]

Да и не только. Выглядит полуфабрикатом

[Anastasia__kot]

Спасибо за совет, почитаю информацию и допишу статью

[mih-kopylov]

Существует два вида JWT токенов: access token и refresh token, которые создаются и используются только в паре

Ещё существует третий тип - ‘id_token‘, который тоже в форме JWT. Это часть OpenID https://ru.wikipedia.org/wiki/OpenID. Представляет собой информацию о текущем пользователей, результат аутентификации. Для его получения чаще всего требуется ‘openid‘ scope.

‘refresh_token‘ не всегда присутствует в парк с ‘access_token‘. Поскольку он позволяет бесконечно обновлять ‘access_token‘, хранить его в браузере небезопасно. Лучше всего хранить его в веб сессии на бэкенде. Там же можно хранить и ‘access_token‘, кстати.
А если бэкенда нет, то и ‘refresh_token‘ не нужен - в этом случае и secret клиента не нужен тоже, для таких открытых клиентов используют расширение PKCE.

[Evengard]

PKCE и с приватными клиентами используется, так-то.

[mih-kopylov]

Конечно, только создан он для публичных

[NaturAll]

В пункте 3.2 в файле api.auth.js, я так понял ошибка и экспортируется class, а не const.

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

[Anastasia__kot]

крутой совет, спасибо!

[elizsid24]

1. Сначала нужно создать функцию для проверки токена. Она должна принимать токен и возвращать либо объект пользователя, если токен верный, либо false, если токен неверный.

2. Затем нужно создать мидлвару для проверки авторизации. Она должна вызывать функцию проверки токена и, если токен верный, передавать управление следующему обработчику, а если токен неверный, возвращать ошибку 401 (Unauthorized).

3. Далее нужно создать маршрут для авторизации. Он должен принимать логин и пароль пользователя, проверять их на соответствие в базе данных, и если они верны, генерировать JWT токен и отправлять его в ответе.

4. Наконец, нужно создать приватные маршруты, которые будут требовать авторизации. Для этого нужно применить мидлвару проверки авторизации к каждому приватному маршруту.

Пример кода на Node.js:

javascript
const jwt = require('jsonwebtoken');

// Функция для проверки токена
function verifyToken(token) {
try {
const decoded = jwt.verify(token, 'secret');
return decoded.user;
} catch (err) {
return false;
}
}

// Мидлвара для проверки авторизации
function requireAuth(req, res, next) {
const token = req.headers.authorization;
const user = verifyToken(token);
if (user) {
req.user = user;
next();
} else {
res.status(401).json({ error: 'Unauthorized' });
}
}

// Маршрут для авторизации
app.post('/login', (req, res) => {
const { username, password } = req.body;
// Проверка логина и пароля в базе данных
const user = { id: 1, username: 'admin' };
const token = jwt.sign({ user }, 'secret');
res.json({ token });
});

// Приватный маршрут
app.get('/private', requireAuth, (req, res) => {
res.json({ message: Hello, ${req.user.username}! });
});

[Anastasia__kot]

это код для бекенда, я правильно понимаю?