Настя Котова // Frontend & Node.js

Интересная тема — как вообще организовывается авторизация в разных проектах.

У кого-то это JWT-токены (тут я когда-то писала про них), у кого-то — сессионные куки, у кого-то и то, и другое.
JWT удобен тем, что сервер выписывает токен, подписывает своим ключом, а клиент просто прикладывает его к каждому запросу. Но если токен утёк, то всё равно до конца его срока жизни он будет валиден — нет никакого механизма отзыва. Поэтому такие токены делают короткоживущими и добавляют второй — refresh-токен, чтобы обновлять сессию.
Дальше начинается самое интересное — где хранить этот refresh-токен. В localStorage небезопасно, в куках — только если httpOnly. А в чистом SPA это уже сложнее, потому что нельзя управлять такими куками с фронта.

Тут кто-то может начать задумываться про Backend-for-Frontend (BFF). Но, как по мне, делать BFF только ради авторизации — странное решение. Это может быть одним из пунктов, но не единственным. Если у вас есть ещё причины (например, хочется проксировать запросы, фильтровать данные или использовать SSR) — тогда да, BFF может дать больше гибкости и безопасности.
В целом, у SPA возможностей в плане авторизации гораздо меньше, чем у фронта с BFF. Поэтому если вы никак не можете менять логику авторизации на бэкенде — BFF может стать неплохим компромиссом.

И ещё важно помнить про блокировку пользователей и отзыв токенов. Даже если JWT живёт неделю, должна быть возможность ограничить доступ человеку, которого заблокировали. Иногда это решается централизованным чёрным списком токенов/сессий, иногда — проверкой статуса при каждом запросе.

Авторизация вообще тесно связана с безопасностью.
Бессмысленно ставить JWT и при этом не защититься от XSS, CSRF и не настроить CSP-политику. Это как поставить стальные ворота, но оставить рядом огромную дыру в стене — мощно, но бесполезно.

Ну и отдельный мир — это SSO (OAuth, OpenID, и вот это всё). Я с ним пока не работала, но тема явно интересная и заслуживает отдельного разбора.
А с чем сталкивались вы? Какие подходы к авторизации вам кажутся удачными, а какие — категорически нет?

🤔5❤3

www.tgoop.com/startpoint_dev/181

380 viewsOct 20 at 13:38

Интересная тема — как вообще организовывается авторизация в разных проектах.

У кого-то это JWT-токены (тут я когда-то писала про них), у кого-то — сессионные куки, у кого-то и то, и другое.
JWT удобен тем, что сервер выписывает токен, подписывает своим ключом, а клиент просто прикладывает его к каждому запросу. Но если токен утёк, то всё равно до конца его срока жизни он будет валиден — нет никакого механизма отзыва. Поэтому такие токены делают короткоживущими и добавляют второй — refresh-токен, чтобы обновлять сессию.
Дальше начинается самое интересное — где хранить этот refresh-токен. В localStorage небезопасно, в куках — только если httpOnly. А в чистом SPA это уже сложнее, потому что нельзя управлять такими куками с фронта.

Тут кто-то может начать задумываться про Backend-for-Frontend (BFF). Но, как по мне, делать BFF только ради авторизации — странное решение. Это может быть одним из пунктов, но не единственным. Если у вас есть ещё причины (например, хочется проксировать запросы, фильтровать данные или использовать SSR) — тогда да, BFF может дать больше гибкости и безопасности.
В целом, у SPA возможностей в плане авторизации гораздо меньше, чем у фронта с BFF. Поэтому если вы никак не можете менять логику авторизации на бэкенде — BFF может стать неплохим компромиссом.

И ещё важно помнить про блокировку пользователей и отзыв токенов. Даже если JWT живёт неделю, должна быть возможность ограничить доступ человеку, которого заблокировали. Иногда это решается централизованным чёрным списком токенов/сессий, иногда — проверкой статуса при каждом запросе.

Авторизация вообще тесно связана с безопасностью.
Бессмысленно ставить JWT и при этом не защититься от XSS, CSRF и не настроить CSP-политику. Это как поставить стальные ворота, но оставить рядом огромную дыру в стене — мощно, но бесполезно.

Ну и отдельный мир — это SSO (OAuth, OpenID, и вот это всё). Я с ним пока не работала, но тема явно интересная и заслуживает отдельного разбора.
А с чем сталкивались вы? Какие подходы к авторизации вам кажутся удачными, а какие — категорически нет?

BY Настя Котова // Frontend & Node.js