Как правильно отдавать обновленные токены в роутах?

Question

[Boris007]

Есть набор роутов, где нужно проверять авторизацию
Но при необходимости новой генерации токенов не хотелось бы их засовывать в req.tokens
И на каждом последующем роуте проверять req.tokens на его наличие
Как из checkAuth можно настроить автоматическую отправку кук, чтобы избавить от логики все остальные роуты?

app.use('/api/v1/users', checkAuth, users)

export function checkAuth(req: Request, res: Response, next) {

    Auth.checkAccess(req)
    .then(tokens => {
        next()
    })
    .catch(() => {
        res.status(401).json('')
    })

}

Стандартный ответ куки при авторизации выглядит так

res.cookie('refresh_token', tokens.refresh_token, { httpOnly: true })
res.status(200).json({access_token: `Bearer ${tokens.access_token}`})

Можно ли, чтобы в каждом роуте api/user, api/friends, api/contacts и т.д. избежать массового добавления кода по типу

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   if(req.refreshToken) res.cookie('refreshToken', req.refreshToken, { httpOnly: true })
   if(req.accessToken) {
      res.status(200).json({data, access_token: `Bearer ${req.accessToken}`})
      return
   }
   res.status(200).json({data})
}

Вместо простого

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   res.status(200).json({data})
}

Где мы до этого в middleware проверяли токены и если их обновляли, то добавляли в reqи делали next()

Или как это правильно делается?

Answer 1

[Daemon23RUS]

Что то мне кажется, вы чего то не договариваете, потому как не помню такой проблемы у себя картинка для уточнения процесса обновления токена.

Comments

[Boris007]

При логине я отправляю через куки рефреш токен и в обычном сообщении аксес токен
Записываю на клиенте в хранилище аксес токен и прикрепляю его при запросах в хедер авторизейшн

Но после возникла проблема, когда я начал создавать роуты, где нужно быть авторизованным
Как с ними делать обновление токенов?

У меня выходит так, что в каждом таком роуте теперь приходится отправлять не просто
res.status(200).json(data)

А уже что-то подобное

res.cookie('refresh_token', tokens.refresh_token, { httpOnly: true })
res.status(200).json(
{
data,
access_token: `Bearer ${tokens.access_token}`
}
)

Т.е. каждый роут приходится сопровождать
Аксес токеном, если мы его обновили
access_token: `Bearer ${tokens.access_token}`

И так же рефреш токеном

res.cookie('refresh_token', tokens.refresh_token, { httpOnly: true })

У меня ответ получается вместо 1 строки уже 5, где 4 с токенами строчки везде одинаковые по всем роутам

И я хотел бы вынести эту логику с обновлением токенов из роутов в middlewareили как-то еще

[Boris007]

Как обрабатывать такой запрос в том случае, если аксес токен закончился?

Ситуация, что у нас закончился аксес токен, но рефреш еще жив.
Мы в middleware обновляем запись в таблице с рефреш токенами и создаем новый аксес токен

Но где и как нам их возвращать пользователю?
Из роута api/user или как-то до него можно это сделать отдельно, а после уже прислать отдельно ответ с api/user?

Суть моего вопроса была в том, можно ли, чтобы в каждом роуте api/user, api/friends, api/contacts и т.д. избежать массового добавления кода по типу

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   if(req.refreshToken) res.cookie('refreshToken', req.refreshToken, { httpOnly: true })
   if(req.accessToken) {
      res.status(200).json({data, access_token: `Bearer ${req.accessToken}`})
      return
   }
   res.status(200).json({data})
}

Вместо простого

router.post('/user', async (req: Request, res: Response): Promise<void> => {
   ... await data
   res.status(200).json({data})
}

Где мы до этого в middleware проверяли токены и если их обновляли, то добавляли в reqи делали next()

[Daemon23RUS]

Boris007,

Вот пример как это можно сделать

apiRouter.use(function(req, res, next) {
      var token = req.body.token || req.query.token || req.headers['x-access-token'];
      if (token) {
        jwt.verify(token, app.get('superSecret'), function(err, decoded) {
          if (err) {
            //Here I can check if the received token in the request expired
            if(err.name == "TokenExpiredError"){
                var refreshedToken = jwt.sign({
                    success: true,
                    }, app.get('superSecret'), {
                        expiresIn: '5m'
                    });
                request.apiToken = refreshedToken;
                next();
              }else if (err) {
                return res.json({ success: false, message: 'Failed to authenticate token.' });
              }         
          } else {
            //If no error with the token, continue 
            request.apiToken = token;
            next();
          };
        });
      } else {
        return res.status(403).send({
            success: false,
            message: 'No token provided.'
        });
      }
    });

Так же посмотрите stackoverflow.com по схожему вопросу. (код оттуда) Это если я правильно понял вашу проблему. (день выдался длинный ...)

[Daemon23RUS]

Boris007, Может вы хотите что то вроде такого

function modify(req, res, next){
  res.body = res.body + "modified";

  next();
} и положите туда все свои "повторяющиеся хотелки"

Тогда есть один момент, если токен протух, а рефреш еще жив, мы отдаем инфу доступную только по действующему токену ?

[Boris007]

Daemon23RUS,
Если аксес токен закончился, но рефреш еще жив, то
1) проверяем рефреш токен на валидность и после с его записью в БД, что это тот же токен
2) если он совпал, то генерируем два новых рефреш и аксес токена
3) записываем в бд новый рефреш токен
4) отдаем данные и рефреш + аксес токены

[Boris007]

Daemon23RUS, но это middleware для проверки токенов
А вот как быть в случае, если нам нужно токены обновить и при этом отдать данные еще, т.к. запрос был для получения данных, а обновления токенов упали прицепом

Т.е. мы в middleware проверки токенов еще должны обновить токены и при этом после пустить дальше на роут для обработки запроса данных, а после отдать данные и новые токены

До этого момента я всегда отдавал данные в виде
res.status(200).json(data)

Но в данной ситуации мне кажется, что придется теперь все ответы переписать под шаблон в виде

res.status(200).json({
data,
access_token,
message,
error
})

Но это так же ляжет доп. нагрузкой на логику в каждом запросе на клиенте, что теперь нужно будет всегда проверять на наличие ключа access_token, что если он есть, то обновить его на клиенте

[Boris007]

Daemon23RUS,
Немного не понял про это, в поисковике тоже не особо статей
Подскажите пожалуйста, что значит
res.body + "modified"; и по какому принципу это работает?

function modify(req, res, next){
  res.body = res.body + "modified";

  next();
} и положите туда все свои "повторяющиеся хотелки"

Что-то похожее я видел в виде, что мы просто делаем

res.body.tokens = tokens
next()

И у нас вроде следующий обработчик в мутированном req уже увидит req.tokens

[Daemon23RUS]

Boris007,

Подскажите пожалуйста, что значит
res.body + "modified"; и по какому принципу это работает?

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

[Boris007]

Daemon23RUS, а как тогда реализуют аутентификацию через токены?
Как их обновляют все, когда запрос идет для получения данных, а аксесс токен закончился и нужно обновить токены?

[Daemon23RUS]

Boris007, Я ранее как раз об этом и писал, что делаем если токен протух а рефреш жив
Ведь данные мы не можем отдать если токен протух. а чтобы на лету его обновить нужен рефреш, который мы по идее каждый раз в запрос не таскаем. А предоставляем только на эндпоинт рефреша, где и получаем новые токен и рефреш. Вот в принципе этот вопрос я и поднимал в своем ответе, что вы что то недоговариваете, или как то по другому реализовываете.

[Boris007]

Daemon23RUS, допустим, я сделал, как в примере, у меня сработал next() и передал дальше данные токенов
Как мне их отправить клиенту?
У меня десятки роутов и в каждом из них нужно повторять код на проверку
if(request.apiToken)
что бы отправить не просто
res.status(200).json(data)

А что-то вроде такого?

res.cookie('refreshToken', request.apiToken)
res.status(200).json({data, accessToken: request.accessToken))

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

[Daemon23RUS]

Boris007, Прежде чем продолжить поиск решения, скажите, Вы рефреш заставляете клиента таскать в каждый запрос ?

[Daemon23RUS]

Boris007, В общем я попробовал у себя, то что хотите сделать Вы (модификацию отправляемых данных) Создал пустой проект с 2мя роутами

фрагмент app.js

app.use('/api',function(req, res, next) {
  var originalSend = res.send;
  res.send = function (){
    let temp=JSON.parse(arguments[0]);
    temp.mw_add="Some Data From Middleware";
    temp.mw_time = Date.now()
    res.cookie('MiddleWare','added after route send')
    arguments[0] = JSON.stringify(temp);
    originalSend.apply(res,arguments);
  }
  next();
});
app.use('/api', APIRouter);

api_route.js

var express = require('express');
var router = express.Router();
const some_api_data={api_value:35,api_status:"Status OK"}
/* GET API page. */
router.get('/', function(req, res, next) {
  res.status(200).json(some_api_data)
});
module.exports = router;

посылаемые данные в роуте {"api_value":35,"api_status":"Status OK"}
принимаемые данные клиентом

{"api_value":35,"api_status":"Status OK","mw_add":"Some Data From Middleware","mw_time":1700082379016}

+ устанавливается кука

Set-Cookie: MiddleWare=added%20after%20route%20send; Path=/

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

[Boris007]

Daemon23RUS, да, рефреш живет в http only cookie и его всегда можно прочитать при любом запросе, он не удаляется
А аксес токен добавляется только в те fetch, где прописан заголовок Authorization

[Daemon23RUS]

Boris007, Я выскажу личное мнении, считайте это мысли вслух.
таскать рефреш в каждый запрос -зло, у этой куки должен быть Path=/api/auth/refresttoken и именно в этом запросе ее надо светить. Именно по этому я все время твержу, что у вас в схеме что то не то.
Вопрос обновления токена вы по какой то причине сняли с клиента и повесили на сервер. И теперь у вас с этим проблема. По факту вы JWT превратили в сессию. Ведь это задача клиента следить за тем, что его токен жив и после просрочки получать новый, для этого есть api/auth/refresttoken а серверное апи путем проброса исключения в ответе tokenexpired на всех роутах апи сообщает клиенту либо данные либо ошибку. И клиент поличив tokenexpired идет обновлять токен, а потом повторяет запрос с новым токеном.
Расскажите где я не прав ?

[Boris007]

Daemon23RUS, т.е. я на клиенте должен проверять жив ли токен или нет, и если нет, то перед запросом на
api/users сделать запрос на api/auth и получив ответ, уже отправить запрос api/users?
А на api/auth как мне получать тогда рефреш токен?
Ведь при новом открытии вкладки у нас пустой клиент и нет токена доступа, как сервер тогда поймет, какой рефреш токен из БД относится к нашему клиенту?

Просто во всех примерах рефреш токен всегда в куках летает и дергается на сервере только при просроченном токене доступа

А вообще, хорошая мысль про то, чтобы проверять токен доступа еще на клиенте и делать два запроса, попробуем )

[Daemon23RUS]

Boris007, Правильно, рефреш токен в куках но летает только на api/auth//refreshtoken, что и указано в его Path=/api/auth/refreshtoken. На api/users этот кукис не летит. Туда летит сам JWT. Так вот мидваре проверяет этот самый JWT на валидность, в том числе и на просрочку. И вот в случае просрочки, мидл бросает исключение, и отправляет что токен просрочен, а сам запрос в этом случае до роута не доходит. Клиент получив от api/users ответ что доступа нет просрочка, идет на /api/auth/refreshtoken, а так как с этим path у клиента есть кука рефреш он ее тянет с собой. /api/auth/refreshtoken возвращает клиенту новый токен и в куку новый рефреш. (ну или ошибку просрочки рефреша и тогда клиент идет на /login)
Клиент успешно получив новый токен, повторяет запрос на api/users
Профит !!!

[Daemon23RUS]

Boris007, Добавлю, чтобы было однозначное толкование Клиент отвечает за получение нового токена, а мидл отвечает за его проверку. Т.е обязанность держать актуальный токен лежит на клиенте