Как сделать авторизацию вебсокет сервера на сервере php?

Question

[sevic]

Нашел вот эту статью: live-notes.ru. Там парень проводит авторизацию http запросом с вебсокет сервера (node js) на основной сервер (php), имитируя запрос от клиентского браузера с куками php-сессий. На php проверяет авторизован ли пользователь или нет. Вопрос: насколько это надежно, ведь куки можно другие подставить и также юзер-агент?

Comments

[Даша Циклаури]

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

[Belarus007]

https://owasp.org/www-community/attacks/Session_hi...

[sevic]

Даша Циклаури, где можно почитать подробные материалы об этом?

[Даша Циклаури]

sevic, на примере JWT, с ними не ошибешься
https://jwt.io/introduction/

[sevic]

Даша Циклаури, Получается 2 токена acces и refresh. Куки должны передаваться клиенту (браузер) с сервера php с параметрами httponly и secure. Вебсокет на ноде и при подключении сервера вебсокет в заголовках нет куки.
Как можно их получить? Допустим если не ставить параметр httponly для куки, то можно при подключении к ноде передать куки в url? Но это уже как я понимаю не безопасно...

[Даша Циклаури]

sevic, например та же oauth позволяет bearer токен получать через query parameters, поэтому можно делать как-то так /ws?access_token=token

как получить: при рендеринге тела страницы на сервере, читается кука и вставляется куда-то в сериализованный state, как и другая инфа при классическом server side rendering

[sevic]

Даша Циклаури, Перечитал кучу статей и форумов про авторизацию на jwt, тяжело все это заходит). Решил, что буду хранить оба токена в куках. Acces будет короткоживущим и доступен для js, refresh долго живущий и не доступен js. Подключение к ws ws//somesite.com?access=token. Также решил прикрутить авторизацию jwt токенов к основному приложению. Но не могу разобраться как реализовать обновление токенов, когда срок жизни access истек. Много инфы для spa приложений. В ajax запросе проверяем жив ли еще access, если нет то запрос на auth/refresh, refresh доступен только по этому пути, проверили - прислали оба токена. Но если приложение не spa? Конечно есть ajax запросы, в них можно проверить access и если он протух запросить обновление. А вот когда заходишь на сайт с браузера по url, допустим, somesite/cabinet. В cabinetController приходит кука acces, она уже не живая. Далее контроллер перенаправляет на обновление: header(location, 'auth/refresh'). Сюда приходит refresh кука, проверяется, отсылаются обе обновленные куки. Все вроде норм. Но в истории браузера сохранится auth/refresh (допустим можно удалить это из истории, когда придут обновленные куки). И еще одно: сам пользователь может набрать такой url somesite/auth/refresh. Думаю, что здесь можно сделать доступ в роуте только с определенным заголовком, например autorization, который будут ставить контроллеры, перенаправляя на рефреш. Будьте добры, подскажите, правильно это или где можно найти информацию об этом.

[Даша Циклаури]

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

Теперь по рефрешам:
Access JWT Token имеет поле exp в него можно записать unix timestamp метку о том, когда же этот токен истечет.

SPA
тут отталкиваемся сколько живет токен секунды/минуты/часы/сутки и в зависимости от этого выбираем интервал проверки на клиенте

setInterval(()=>{
/*
1й момент - честные access token
проверяем если до exp осталось меньше минуты/скольки то секунд (от интервала и времени токена отталкиваемся), то делаем запрос на сервер с refresh
2й момент - черные списки
стандарт не предусматривает возможности "обнулить токен" на других устройствах или еще где-то, например когда ты меняешь пароль или просто хочешь чтобы все токены протухли, НО
можно реализовать на сервере в быстром хранилище (redis) черные или белые списки с токенами (при выдаче заносить с временем экспирации) и уже строить логику на сервере и проверять не только сигнатуру (что подписан тем же сервером) но и нахождение в черном списке. Нужно ли это проверять тут в setInterval не скажу - зависит от приложения
*/
}, /* обычно раз в 10-60 секунд*/);

Что касается WS: сложнее, потому что можно внутри setInterval или рвать соединение и коннектить с новым токеном или на сервере при выдаче токена продлять метку жизни соединения. Тем не менее при установке соединения на сервере стоит ставить метку до какого времени можно оставаться подключенным и в каком-то общем потоке раз в минуту пробегаться по всем соединениям, проверять и обрывать если что

НЕ_SPA
Тут проще, посколько у тебя каждый запрос к серверу и так должна проверяться валидность токена (сигнатура/время жизни), это реализуют в middleware и в либах jwt как правило для серверной стороны эти проверки уже реализованы. Это, кстати, логично и для ajax запросов с клиента, эти запросы тоже проходят через jwt middleware. Просто в случае SPA мы как бы явно делаем оптимизацию тем, что если заведомо еще на клиенте предполагаем что токен невалиден, то не делаем с ним запрос, а вместо этого перед этим делаем рефреш.

Отвечая на вопрос о cabinetController, это же контроллер серверный? В таком случае он не должен выставлять куки протухшие. Логика такая:
1) пришел запрос на контроллер с двумя куками: access, refresh
2) если access == ok выставляем старый access, refresh
3) если access != ok проверяем refresh, если refresh == ok то на серверной стороне получаем новый access и refresh по существующему рефрешу, не надо получение вести через клиента - это будет оверхэд, если можно на сервере сделать
выставляем новый access, новый refresh
4) если refresh != ok , шлем куки на удаление access, refresh таким образом в этом кейсе контекст авторизации будет "неавторизован"

[sevic]

Даша Циклаури, Да, в jwt можно запихнуть много информации (exp, iss, sub...), с этим в общих чертах разобрался.

WS - согласен, здесь нужно будет продумывать логику подключения и разрыва соединения.

Получается что при запросе на сервер нужно будет всегда отправлять обе куки?

[Даша Циклаури]

sevic, насколько помню суть кук в том, что по умолчанию они отправляются на сервер при любом запросе, даже если это картинка. Ясно, что можно при fetch рулить через credentials
Отвечая - да, обе отправляешь, обе приходят или обе удалены

[sevic]

Даша Циклаури, спасибо.