Я прочитал довольно много SO-тем о аутентификации и авторизации с помощью REST и Angular, но я все еще не чувствую, что у меня есть отличное решение для того, что я надеюсь сделать. Для некоторого фона я планирую создать приложение в AngularJS, где я хочу поддерживать:

Ограниченный гостевой доступРолевой доступ к приложению после проверки подлинностиАутентификация через API

Все вызовы REST API должны выполняться через SSL. Я хотел бы собрать приложение, не нарушая принципов RESTful, а именно, не сохраняя состояние сеанса, хранящееся на сервере. Конечно, все, что делается для авторизации на стороне клиента, должно быть усилено на стороне сервера. Поскольку нам нужно передавать полное состояние с каждым запросом, я знаю, что мне нужно передать какой-то токен, чтобы внутренний сервер, получающий запрос REST, мог как аутентифицировать, так и авторизовать вызов.

С учетом сказанного мой главный вопрос касается аутентификации - каковы здесь лучшие практики? Кажется, обсуждается много разных подходов, вот только некоторые из них, которые я нашел:

http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.htmlhttp://frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

Был задан похожий вопрос (AngularJS лучшая практика аутентификации приложений), но если я неправильно понимаю ответ, то, похоже, подразумевается, что следует использовать сеанс сервера, что нарушает принципы RESTful.

Моя главная проблема с Amazon AWS и статьей Джорджа Риза заключается в том, что предполагается, что потребитель - это программа, а не конечный пользователь. Общий секрет может быть выдан программисту заранее, который затем может использовать его для кодирования вызовов здесь. Это не тот случай - мне нужно вызвать REST API из приложения от имени пользователя.

Будет ли этого подхода достаточно? Допустим, у меня есть ресурс сессии:

POST / API / сеанс

Создать новый сеанс для пользователя

Чтобы создать сеанс, вам нужно POST-объект JSON, содержащий «имя пользователя» и «пароль».

{
    "email" : "[email protected]",
    "password" : "password"
}

Пример завитка

curl -v -X POST --data '{"username":"[email protected]","password":"password"}' "https://app.example.com/api/session" --header "Content-Type:application/json"

отклик

HTTP/1.1 201 Created {
    "session": {
        "id":"520138ccfa4634be08000000",
        "expires":"2014-03-20T17:56:28+0000"
    }
}

Коды состояния

201 - Создан, новый сеанс установлен400 - неверный запрос, объект JSON недействителен или отсутствует необходимая информация401 - Несанкционированный, проверка комбо электронной почты / пароля403 - Доступ запрещен, отключена учетная запись или лицензия недействительна

Я опускаю детали HATEOAS для ясности. На бэкэнде будет создан новый, сессионный ключ ограниченной продолжительности, созданный и связанный с пользователем. При последующих запросах я мог передать это как часть заголовков HTTP:

Authorization: MyScheme 520138ccfa4634be08000000 

Тогда бэкэнд-серверы будут отвечать за усвоение этого запроса, поиск связанного пользователя и применение правил авторизации для запроса. Вероятно, следует обновить срок действия сессии.

Если все это происходит через SSL, я оставляю дверь открытой для любых атак, от которых я должен защищаться? Вы можете попытаться угадать ключи сеанса и поместить их в заголовок, поэтому я полагаю, что я мог бы дополнительно добавить GUID пользователя к ключу сеанса для дальнейшего предотвращения атак методом перебора.

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