SPA и REST API — как грамотно построить аутентификацию?

Добавил ответ по этому поводу.

+1 за использование JWT
https://auth0.com/blog/angularjs-authentication-wi...

p.s. причем он зарекомендовал себя именно на практике

Помогите получить Token и DeviceCode из аккаунта сайта. Нужно на постоянной основе, по поводу оплаты договоримся. Если заинтересованы пишите в телеграмм https://t.me/Vot_ya.

xmoonlight,

используя учётные данные, сохранённые на клиенте

что?

davidnum95, учётные данные - это хешированные логин+пароль с публичным ключом сервера. При утере устройства - сервер отзывает свой ключ для данного клиента и хеш учётных данных, хранимых на клиенте, становится невалидным и по нему нельзя авторизоваться даже с правильным логином и паролем.

xmoonlight, поздравляю вас, вы изобрели сессии в каком-то велосипедном варианте.

pavelkunyavskiy, Ладно, я хоть на что-то гожусь) А что Вы изобрели?))

xmoonlight, зачем изобретать то, что давно изобретено, а не лучше ли научится пользоваться тем, что проверено? Или вы уверены что что-то лучше сделаете? Чето сомневаюсь.

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

pavelkunyavskiy,

Вы - зловредитель, везде сующий свою бложик.

Докажи!

Чет непонятно ничего. Когда сервер может вернуть chain-token?

Пункт номер 2 тоже не понял - нужно что-то хэшировать на клиенте? Использую timestamp? Откуда? С клиента?

Можно даже на примере попробовать. Вот у меня есть token: qwefasf, я хочу получить данные /get/books. Как будет выглядеть мой запрос?

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

Что за прозрачным режим получения токена? Предлагаешь на клиенте хранить логин-пароль пользователя?

DTX, я готов объяснить.
Предлагаю тебе создать в draw.io схемку и мы вместе её поправим и всё станет понятно.

xmoonlight, скиньте потом ссылку всем, пожалуйста :)

xmoonlight, не пойму, зачем нужна какая-то схемка. Я же вроде задал вполне конкретные вопросы.
*с draw.io не работал

DTX, без схемки - без вариантов на них отвечать, т.к. они породят ещё факториал числа уже заданных)

Борис, Не вопрос. Главное, чтобы схемку кто-то нарисовал для начала, похожую на правду)

xmoonlight, так?
https://drive.google.com/open?id=1709JbemswPHOCMcn...

DTX, нет. это схема вопроса)
Ладно, вот нашел готовую:

xmoonlight, ну вот первый пункт из ответа ясен - отправляем логин-пароль, получаем токен. Готово, на клиенте есть токен, так?
Дальше в пункте 2 написано, что надо что-то отхешировать, используя timestamp и random. Это на клиенте происходит?
Или имеет ввиду как раз пункт два с картинка? Если так, то в ссылке из ответа, логика работы rest расписана очень коряво.

DTX, мы сейчас про что говорим? про мою статью или про jwt ?!

xmoonlight, про твою статью)

DTX, а причём тут jwt тогда?)))

xmoonlight, так я вроде ни слова про jwt не сказал) Первый мой коммент был для ответа, а не для комментов)

DTX,
1. Данные авторизации храним в хешированном виде (AuthHash) на клиенте после хотя бы одной успешной авторизации, которые хешируем присланным от сервера ключом клиента с лимитированным временем использования.
2. Когда авторизуемся повторно - мы отсылаем AuthHash и подписываем достоверность ключом сервера. Если подпись верна и ключ не отозван на сервере - клиент считается авторизованным и сервер возвращает токен сессии для дальнейшей подписи всех сообщений в данной сессии этим токеном.
3. При обмене данными - сервер может вернуть новый токен сессии. Это означает, что все последующие запросы должны подписываться уже им.
4. Параллельные запросы: если сервер поменял токен - все активные запросы завершаются со старым, все последующие или не успевшие пройти валидацию на сервере со старым токеном - пересоздаются с новым токеном.
5. Для предотвращения перебора, используется два параметра: RANDOM и TIMESTAMP. Они всегда участвуют в каждом формировании запроса к API вместе с данными payload (полезная нагрузка: именно работа с API).

xmoonlight,
1. Идея хранения AuthHash на первый взгляд выглядит интересной. Но что если злоумышленник уведет AuthHash к себе? Он получит полный доступ до тех пор, пока пользователь не поменяет пароль? При этом пользователь даже не узнает, что кто-то сидит в его учетке.
2. Какой ключ может быть отозван на сервере? Пытаюсь понять, как мы проверяем AuthHash.
3. А если последующий запрос будет подписан старым токеном? Клиент получит ошибку и заново авторизуется по AuthHash?
6. Сколько живёт токен сессии? Его можно отозвать?

DTX,
1. Ключ привязывается к клиенту (ClientID, например к подсети или ID-устройства и т.д.). Как доп. защита, на сервере создаётся поведенческий фильтр (на всякий случай), например тот, кто украл ключ решил зайти с той же сети, но ночью.
Сервер попросит пересоздать ключ на основе текущего, а вот тут уже нужен чистый логин и пароль, которого на устройстве нет)
2. Ключ может быть отозван любым другим клиентом (клиент - это ПО) после успешной авторизации или сервером по любому событию. Ключ - это публичный ключ сервера привязанный к конкретному клиенту (НЕ К АККАУНТУ!)
3. Получит ошибку - да. Заново - у клиента уже есть новый хеш (в памяти). Ему нужно переподписать новым и повторно отправить тот же запрос к API.
6. С токеном сессии - уже можно поступать как душе угодно, в зависимости от криптостойкости алгоритма и важности передаваемых данных. Можно хоть каждый запрос его менять (если это необходимо), так называемый chain-token. Можно попросить сервер выдать новый с клиента, а может сервер сказать, что по какой-то причине (не важной для клиента), он просит сменить токен сессии.
Тоже самое - с таймаутами. Но достаточно обычно в 5-10 секунд таймаут ставить для токена между пакетами. И более - для более длинных цепочек обмена без смены.

1. Т.е. для использования с мобильным интернетом данный способ не подойдёт? Это если использовать IP. Если рассматривать spa, то непонятно, как получать clientID. Если
2. А если ответ с новым ключом ещё не получен? В общем, на реализацию этого пункта я бы с удовольствием посмотрел. Это одна из причин, почему было решено оказаться от jwt.
6. Т.е. мало живёт токен, если я правильно понял. Это ещё один гвоздик к размышлениям из пункта два.

DTX,
1. Почему не подойдёт? ClientID=DeviceID. IP можно привязывать как подсеть, а не как IP-адрес. А подсеть - можно получить от провайдера и т.д. Можно не привязывать к IP вообще. Это вопрос уже реализации клиента.
2. Если ответ не получен и соединение открыто - значит его по факту нет и он не вступил в силу на сервере. Старый ключ - работоспособен до тех пор, пока сервер не завершит передачу нового на клиент и не закроет соединение.
6. Токен живёт ровно столько, сколько нужно Вам.

xmoonlight,
1. Потому что с помощью javascript не получить нормальный deviceID.
С мобильного интернета перешёл на вай-фай и подсеть уже другая.
Допустим, злоумышленник угнал таки AuthHash. Он получает полный доступ?

2.
Такая же ситуация возможна? И токен в обоих случаях протух и его надо обновить.
Без реализации такое сложно обсуждать, и я сомневаюсь, что такое можно нормально реализовать)

В общем, если я хоть что-то правильно понял, то это что-то вроде jwt, и моё мнение на его счет не изменилось, несмотря на то, что я бы сильно этого хотел)
И отдельное спасибо за потраченное время :)

DTX, 1. Допустим, AuthHash привязан к устройству на основе возможностей (device capability) и AuthHash - не так просто украсть из кук браузера, если выставлен флаг http security - такие не получить через JS, но получить через http-запрос с сервера.
2. Все протухшие токены - ВООБЩЕ не проблема. Это происходит автоматом: диалог клиента с сервером без участия юзера. Если как на картинке - то по цепочке токены перевыписываются и передача продолжается.
3. Да, и это намного лучше, чем jwt однозначно, т.к. это наиболее гибкое, простое и надёжное решение.

xmoonlight, что значит "привязан к устройству"? Для примера можно взять айфон. Планируется использовать куки для AuthHash?

DTX, я просто для понимания задам встречный вопрос: что Вы называете куками, а что идентификатором устройства?

DTX, кстати, вот про что я говорил выше (подтверждение вот прям из ответа motomac ):

Время жизни JWT-токена лучше ставить небольшое (например, 1 час), потому что отозвать его нельзя.

В этом главный минус JWT. Т.к. если украдут - то всё...

xmoonlight, я пытаюсь подойти со стороны использования этой технологии для spa-сайтов.
Я так понял, что AuthHash хранится не в localStorage, и сделал вывод, что он хранится в куках.
Куки - https://ru.wikipedia.org/wiki/Cookie

Что такое идентификатор устройства я пытался понять несколько сообщений тому назад. Чтобы не засыпать вопросами для себя сделал вывод, что это уникальная строка, идентифицирующая конкретное устройство (браузер в общем случае). Как его получить - мне тоже очень интересно)

DTX,
1. Для браузера - всё верно: храним в куках! Там самое безопасное и надёжное место.
Как я уже выше сообщал, что есть куки с флагом "secure" и httpOnly. Их данные недоступны никаким веб-скриптам. Они используются только для сервера в HTTP-заголовках. Сервер может сказать браузеру: "Установи", "Дай значение", "Удали". При этом через document.cookie - будет невозможно получить куки из Cookie's-хранилища с флагом httpOnly и secure-cookie.

HttpOnly Optional
HTTP-only cookies aren't accessible via JavaScript through the Document.cookie property, the XMLHttpRequest and Request APIs to mitigate attacks against cross-site scripting (XSS).

2. ID-устройства - это уникальный идентификатор.
2.1 В приложениях - обычно это hash на основе данных HW-компонентов, которые нельзя поменять. В Android - есть ADID. Полный список параметров, по которым мы можем формировать HASH - можно увидеть здесь
2.2 Для браузера - применяется технология отпечатка пальца "fingerprint". Подробно, можно почитать здесь. Она используется крупными финансовыми организациями и банками!

stateless

pavelkunyavskiy, stateful ничем не лучше stateless. Один sql запрос в 2018-ом ничего не стоит.

Alex Wells, так в том-то и дело, что stateful всем хуже чем stateless))) Дело не в SQL запросах, а запросах с разных доменов, хостов.

pavelkunyavskiy, извиняюсь, перепутал. Stateful = cookies, а steteless - это полный бред. Возня с ним, невозможность обновления данных - все бред.

Если нужны "разные хосты, домены", то можете на крайняк использовал stateful. В любом месте, где вам потребуется юзер (в примере с stateless), вам почти стопроцентно потребуется и другая инфа с места, где этот токен был создан. Посему такое сомнительное рассоеденение разных частей бека - бред, ибо в реальной жизни такого не бывает (почти).

Alex Wells, так эту инфу можно положить в пейдоад токена. Никакие сессии не дадут такого удобства.

JohnDaniels: Тем, что пакеты трафика должны быть уникальными и никогда не повторяться.

xmoonlight, а могли бы подробнее этот момент осветить?

Борис, при передаче payload-параметров (для API) мы передаём ещё два: RANDOM и TIMESTAMP. Подписываем запрос к API с участием всех параметров: payload, RANDOM, TIMESTAMP и SALT. Секретный ключ (и/или SALT, "соль") - не пересылаем никогда (надеюсь, это понятно и так...).
В итоге, при отправке одних и тех же payload-данных мы всегда будем получать уникальный хеш для одного и того же пакета payload.

xmoonlight, это я понимаю. Но почему пакеты должны быть уникальными?
А если есть сессия, и передаются тупо данные и идентификатор сессии – какие в этом минусы?

Я понимаю: подделать не получится. А если это не так критично для проекта?
Я сейчас склоняюсь к варианту HTTPS + сессии. Что я при этом теряю?

Борис, если не так критично - то можно делать так как считаете нужным.
Что теряете - доверенную инкапсуляцию. Т.е., минус один слой защиты.

а какой в итоге у вас получился рабочий вариант?

Борис,

DTX, да, соблазн большой и выглядит проще всего, вся инфраструктура уже есть и работает.
А минусы какие?