SPA. Способ аутентификации и перехода между доменом и поддоменом?
Есть лэндинг страница на которой имеется форма ввода логина и пароля, например, domain.com. И имеется SPA приложение на app.domain.com, на которое идет редирект после логина на лэндинге.
Как более секьюрно сделать аутентификацию по API между доменом и поддоменом, чтобы после редиректа, не беспокоиться за токен?
Тут именно еще интересует как отдать токен от домена на поддомен?
Вариант 1. Залогиниться в domain.com и передать в качестве GET параметра пллученный токен - очень не секьрно, т.к. легко токен светится в строке браузера, да и впринципе везде в запросе.
Вариант 2. Поставить куки token=mytoken в домене и взять их в поддомене. Немного сомневаюсь, Т.к. при любой случайной xss токен можно спереть (конечно, тут нужно следить, чтобы xss не было, но все же, вероятность есть).
Подскажите, пожалуйста, более надежный способ.
Спасибо!
Самое простое решение - токен авторизации должен быть одноразовым
при авторизации сгенерили одноразовый токен и передали его любым способом приложению
приложение конектится к серверу с этим токеном, 2й раз его уже не использовать, дальше идет либо вебсокет соеденение без всяких токенов, либо, если все же ajax, генерим другой постоянный токен сессии, который храним на клиенте в замыкании.
Вариант посложнее, читаем про цифровой отпечаток браузера.
Смысл в том что есть некая функция, если вызвать ее из одного и того же браузера - она будет возвращать постоянное значение, но в разных браузерах это значение будет отличаться (например chrome одной и той же версии, на одной и той же версии ос выдает разное значение у меня на десктопе и на ноуте).
Если все это осилите, проблем, как с помощью этого обезопасить сессию от использования на другом девайсе, возникнуть уже не должно
Дмитрий Беляев Благодарю за ответ. Очень интересно про цифровой отпечаток. Хотелось бы услышать Ваше мнение по хранению токена в первом варианте, для восстановления сессии. Я так понимаю, только установкой http only cookie? Спасибо.
IDDH: в 1 варианте особой разницы нет, можно хоть через get запрос, хоть через хэш передавать, а чтоб глаза не мозолил на js очищать.
Например редиректите на app.domain.com/#token
на целевой странице его считываете и очищаете:
var token = location.hash.slice(1);
location.hash = '';
Дмитрий Беляев Вы меня немного не поняли, я имею ввиду под восстановлением сессии - хранение токена в каком нибудь хранилище, чтобы при следующем заходе еще раз не логиниться, а продолжить работу без ввода логина и пароля.
IDDH: варианта опять таки 2 тут:
1) cookie - браузер будет автоматом отправлять их с каждым запросом, где совпадает путь (большинство пишут в путь корень сайта и не заморачиваются)
2) localStorage - тут уже отправлять придется самостоятельно скриптами
к любому хранилищу можно получить доступ через скрипты на странице или через инструменты разработчика, так что хранение сессии между сеансами в любом случае уязвимо для xss или прямого доступа к браузеру
Дмитрий Беляев Спасибо за ответ. В случае флага HttpOnly в cookie, они не доступны с javascript. Поэтому в случае возможности установки этого флага на сервере, думаю это защитит от xss. А вот через инструменты разработчика, да, тут уже сам пользователь отвечает за себя :)
