AngularJS атворизация в приложении

Cookie?

отдача тех или иных страниц

В смысле partial'ов и вообще HTML? Если не пре-рендеришь — нафиг не надо, тупо храни статус авторизации (а статус авторизации проверять при собственно передаче данных). Если пре-рендеришь (с angularjs? знатное извращение) — он опять же ни при чём, тебе всё равно на бэкэнде проверять.

все ровно сессии нужно хранить на стороне сервера

Необязательно. Но если не хранить на стороне сервера — жди replay-атак, хотя ограничение времени действия слегка поможет.

А вообще — никто не мешает тебе дублировать сессию целиком либо какие-то важные части в кукизах, только не забудь про здравый смысл и не ставь/читай это бэкэндом.

Cookie как самое простое.

С токенами больше возни и подводных камней, их имеет смысл делать тогда, когда у тебя твой api-сервис работает не только для angular, но и для каких-либо других приложений, для которых токены удобнее (что-то мобильное, например). Или когда есть отдельное приложение, выдающее токены на несколько сервисов, или вообще сторонний провайдер авторизации.

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

А если попробовать html5 data storage там есть два вида сессий? Или все таки механизм с cookie себя лучше отработает?

Есть аутентификация. Есть авторизация. Эти вещи используются как на клиенте, так и на сервере. С чем конкретно возникли проблемы?

А если попробовать html5 data storage там есть два вида сессий? Или все таки механизм с cookie себя лучше отработает?

Ты про localStorage и sessionStorage? Это не замена cookie как таковая, а просто механизм хранения данных. Я бы не советовал хранить данные, связанные с авторизацией, только на клиенте, хотя некоторые вроде не боятся так делать, используя различное шифрование.

Если у тебя на сервере будут сессии, то тебе придётся с каждым запросом слать id этой сессии, чтобы сервер проверял, залогинен ты или нет. Соответственно, в случае с куками браузер будет делать это сам, отсылая нужное. В случае с токенами ты будешь слать их вручную в каждом запросе (в заголовках или в url-е, или внутри json, например), а между запросами хранить токен в этих самых storage. В данном случае разница между куками и токенами не такая и большая, только что с токенами возни больше.

А что, обычная POST-форма уже не в моде? :-) для авторизации - самое оно, зачем чудить?

Проблем пока никаких нету) Продумываю механизм авторизации пользователей учитывая что весь front-end написан на angular и от сервера изолирован.

А можешь, пожалуйста, более подробно описать. Мне просто не приходилось писать полноценный механизм авторизации ранее. Я понимаю механизм cookie, но вот в чем смысл, мой front-end чисто на angularи крутиться на apache, а на dev сервере на nginx, а apiвообще на другом сервере, выходит мне нужно чисто на стороне angular посредством javaScript формировать cookie и в том же приложение в другой части его как-то проверять, потому что слать все это на сервер где api как я понял - не совсем то. Или я не правильно понял, можешь описать просто подробнее этот механизм?

В случае с cookie браузер будет сам слать их.

Твоё приложение шлёт post-запрос от формы с логином и паролем, сервер в ответ отдаёт cookie. Далее браузер сам будет слать этот cookie со всеми запросами к серверу (там вроде про withCredentials не стоит забывать, но сейчас я точно не скажу, это в гугл).

Соответственно, внутри angular-а ты проверяешь, что тебе отдаёт сервер. Если твой cookie был верный, то сервер отдаёт контент, если нет - 403. В случае получения 403 ты перекидываешь юзера на страницу логина обратно.

Годное чтиво

У меня api и front-end на разных хостах, выходит сервер будет формировать cookie для первого хоста на котором и висит front-end, или тот первый хост пользователю запишет уже эту cookie?

Сервер будет давать cookie для своего хоста, естественно.

Вот у тебя есть mysite.com и api.mysite.com. На mysite.com висит angular, ничего ценного нет, только js и html. Приложение запрашивает данные с api.mysite.com. Допустим, мы хотим сделать так, чтобы незарегистрированным пользователям ничего увидеть было нельзя.

При заходе на mysite.com через angular делается запрос к api.mysite.com/check (например). На api.mysite.com серверная часть проверяет, пришло ли куки, если нет, то выдаёт 403. Соответственно, angular, получив 403, перекидывает пользователя на страницу с логином и паролем. Если пользователь там вводит нужные данные, то angular делает запрос к api.mysite.com, там проверяется логин с паролем, и, если всё ок, выдаётся cookie в ответ.

Далее при любом запросе angular будет слать этот cookie к api.mysite.com. Соответственно, на сервере каждый раз будет проверяться, залогинен пользователь или нет, и, если нет, в ответ пойдёт 403, а angular перекинет на страницу с логином и паролем.

Хост, на котором у тебя висит фронтенд, вообще трогать не надо, там же ничего кроме шаблонов да js-а нет.

Всякие нюансы реализации, типа interceptor-ов на ответы сервера, можно подсмотреть по любой из ссылок выше (что для токенов верно, то и для куки примерно так же будет работать).

С токенами, в общем-то, то же самое, только надо их самому цеплять к http-запросу, а куки цепляются силами браузера самостоятельно.

Вот теперь ясно, но вот теперь надо продумать как правильно отдавать те или иные страницы конкретным группам пользователей, думаю писать сервис и отталкиваться от $routeChangeStart;