Первое и одностраничное приложение Api

Я создаю одностраничное приложение и REST API для обработки запросов от клиента и любого возможного стороннего клиента.

Моя идея состоит в том, чтобы создать три сервера:

  • A — API на основе OAuth.
  • B - Статика с файлами html/css/js + partials/views
  • C — веб-сервер (узел, Python или что-то еще), который обрабатывает вход в систему.

Возможно, четвертый обрабатывает сеансы с Redis или чем-то еще.

Я хочу, чтобы SPA заставил пользователя зарегистрироваться и/или войти на сервер C, дать ему токен доступа и позволить ему напрямую общаться с API (A).

Мой вопрос в том, каков правильный механизм для решения этой проблемы?

  • Установить файл cookie сеанса с токеном доступа внутри для основного клиента приложения (SPA), чтобы он мог взаимодействовать с REST API, пока существует сеанс.
  • Чтобы избежать создания сервера C и обработки аутентификации на сервере A (как насчет сторонних сервисов?)
  • Что-нибудь еще

Мой вопрос немного запутанный, поэтому не стесняйтесь спрашивать меня о более подробной информации.


web rest security single-page-application oauth
person Asdine    schedule 25.03.2013    source источник
comment
Я задал аналогичный вопрос некоторое время назад, но не получил много отзывов: stackoverflow.com/questions/15362639/ - однако я бы посоветовал начать с простого (r)...   -  person poseid    schedule 25.03.2013
comment
Да, я уже видел этот вопрос и многие другие, но, к сожалению, он не прозвучал для меня достаточно ясно. Что вы подразумеваете под простым (r)?   -  person Asdine    schedule 25.03.2013
comment
оставьте OAuth для начала ... может быть, вы можете использовать только подписанные запросы?   -  person poseid    schedule 25.03.2013

Ответы (1)


arrow_upward
0
arrow_downward

То, что вы в основном описываете, является системой «билетов», только вы называете билет «жетоном». Эта проблема решалась по-разному с помощью различных стандартизированных протоколов в течение ряда лет. В Массачусетском технологическом институте разработан очень популярный открытый стандарт Kerberos.

Если возможно, я настоятельно рекомендую использовать существующий протокол и существующую реализацию. Попытка «свернуть свою собственную» защиту очень и очень сложна и обычно приводит к уязвимости приложения. Подумайте о чуме, которая преследовала Microsoft на протяжении многих лет, по сравнению с относительно надежной репутацией систем *nix :-)

Мой первый подход состоял бы в том, чтобы принять Kerberos или другой подобный протокол. Если вы твердо намерены свернуть свой собственный, то чем проще, тем лучше. Я бы выбрал что-то вроде вашего второго решения и отказа от сервера C. Слишком много места для ошибки, когда другой сервер выполняет аутентификацию.

Я знаю, что это не совсем тот ответ, на который вы надеялись, но я надеюсь, что это поможет.

person Freedom_Ben    schedule 25.03.2013
comment
Я не обязательно хочу настраивать систему продажи билетов, но это хороший способ выполнить аутентификацию для моей системы. Я только что открыл для себя мир одностраничных приложений, и мне интересно, как быть с безопасностью и аутентификацией. Спасибо за ваш ответ кстати :) - person Asdine; 25.03.2013