Как сделать правильную авторизацию на Vue.js?

Question

[Максим Власов]

Делаю приложение в связке Vuejs + Laravel и возник такой вопрос: каким образом сделать именно правильную авторизацию. Во всех мануалах говорится, что хранить токен нужно в localStorage. Но ведь это не очень безопасно. По идее обычный ajax запрос с логином/паролем может авторизовать пользователя по cookie. Тогда почему в статьях говорится о ключе авторизации? Как по мне, то ключ нужен для авторизации, если нет возможности использовать куки. Или я не прав?

Answer 1

[ShinShil]

В плане безопасности и токен, и куки равны. Под безопасностью имею ввиду сложность взлома.

Можно выделить несколько основных отличий:
1. Куки - хранятся на сервере и на клиенте, токен - хранится на клиенте
2. Куки привязываются к домену, который авторизовался, а токен нет - это даёт большую гибкость, и она становится необходимостью при разработке распределённых систем.
3. Токен можно использовать выборочно на запросах, а куки на всех запросах. В случае с куки, это может привести к XSRF атакам, т.к. после авторизации, все запросы будут считаться авторизованными. Например, ты авторизовался на сайте site.com, я отправил тебе письмо с таким тегом:

<img src="https://site.com/money?money=200&to=me />

. В результате мне перечислит 200 единиц, т.к. после авторизации с куки, все запросы считаются авторизованными и запрос https://site.com/money?money=200&to=me отработает. Способы защититься от таких атак существуют.

В последние пару лет токены стали чаще использовать, по трём причинам:
1. Они stateless, что больше соотвествуют SPA (angular, vue, react) - один из моментов SPA в том, что состояние клиента находится на клиенте.
2. Гибкость, т.к. токены не привязаны к одному домену
3. Они набрали популярность))

За последние два года лично мне не попадалось проектов с куки-авторизацией, стек .net + angular/react

https://dev.to/spukas/authentication-cookies-vs-to...
https://stackoverflow.com/questions/17000835/token...
https://www.linkedin.com/pulse/cookie-vs-token-aut...

Comments

[Figment]

Позвольте спросить, что имеется в виду под "куки" и как они хранятся на сервере?
Те куки, о которых я знаю (cookie) хранятся в браузере и к ним есть прямой доступ.

[Roman K]

Бред так бред. Особенно порадовало "В плане безопасности и токен, и куки равны"

[ShinShil]

Roman Kitaev , поясните пожалуйста свою точку зрения

[ShinShil]

Figment, имел ввиду, что в случае с куки, мы получаем их на клиенте, и в то же время они хранятся и на сервере, когда мы шлём запрос, то сервер сверяет куки с тем значением, которое там хранится.

Answer 2

[tvsjke]

Использовать JWT

По поводу хранения:

Cookies при правильном использовании являются адекватным и наиболее безопасным на данный момент решением для хранения JWT Access токена и должны следовать следующим правилам:

• Быть установленными для API домена/пути чтобы избежать оверхеда при запросах к статичным файлам (публичным картинкам/стилям/js файлам).
  
  
• Иметь флаг Secure (для передачи только по https).
  
• Иметь флаг httpOnly (для невозможности получения доступа из JavaScript).
  
• Атрибут SameSite должен быть Strict для защиты от CSRF аттак, запретит передачу Cookie файлов если переход к вашему API был не с установленого в Cookie домена.
  

На стороне сервера так же должно быть настроено:

• Content-Security-Policy – ограничение доверенных доменов для предотвращения возможных XSS атак
  
• Заголовок X-Frame-Options для защиты от атак типа clickjacking.
  
• X-XSS-Protection – принудительно включить встроенный механизм защиты браузера от XSS атак.
  
• X-Content-Type-Options – для защиты от подмены MIME типов.
  

Соблюдение этих мер вкупе с частой ротацией Access/Refresh токенов должно помочь обеспечить высокий уровень безопасности на сайте.

Отсюда

Comments

[ShinShil]

Частая ротация - это да, но по поводу хранения их именно в куки мне кажется оверхедом.

1. Если кто-то другой получит ваш токен. Чтобы получить access token, нужно скопировать его вручную из local storage браузера, если у потенциального "хакера" есть такого уровня доступ к пользовательской машине, то скорее всего уже ничего не поможет.
2. Если пользователь сам передаст кому-то токен. Ему также ничто не мешает самостоятельно передать свои логин и пароль.
3. Перехват заголовков. Что с токенами, что с куки есть своих защитные механизмы

Мне кажется, более важно грамотно настроить политики доступа, чтобы, например, рядовой пользователь мог вызывать только разрешённые ему действия. Тогда он никак не грохнет систему. Его токен будет обладать только минимальными правами. А за утечку логина и пароля отвечает в том числе сам пользователь.

Answer 3

[segio_tt]

Если совсем уж безопасно, то нужно 2 токена , один основной а другой рефреш который обновится с каким то интервалом.

Comments

[tvsjke]

Интересно, а как два токена вместо одного обеспечат "совсем уж безопасно" ?
Рефреш токен все также хранится на клиенте, со всеми отсюда вытекающими